Your data,
well kept.

Purpose and scope

This policy applies to:

• the Minori web application, API, and iOS and Android applications;
• databases, the production server in Montréal, Coolify and scheduled jobs;
• vendor accounts: Plaid, AWS, GitHub, Apple, Google, domain registrar, email;
• workstations and devices used to administer these systems;
• anyone who accesses these systems, including contractors.

Roles and responsibilities

• The security lead approves this policy, maintains the registers (access, incidents, exceptions, end-of-life software), grants access, and answers requests from users and authorities. The security lead is also the person in charge of the protection of personal information under Québec’s private sector privacy act.
• A contractor or employee accesses systems only after signing a written confidentiality agreement, with only the access required for the assignment. Access is removed on the day the assignment ends.

Data classification

Development and staging environments use fictitious data only. Real data exists only in production.

Access control

• Least privilege. Each person and each service receives only the rights it needs.
• Separate database roles. The migration role is separate from the application role, which has no direct read access to bank secrets. Those are reachable only through controlled functions bound to the owner of the connection.
• Named accounts. No shared administrator account.
• Server access with SSH keys only, password authentication disabled. The database is not exposed to the internet.
• Access to a user’s data only to answer that user’s request, handle an incident or meet a legal obligation. Every such access is logged.
• Quarterly review of all access (server, Coolify, database, vendors), recorded in the access register.
• Removal of access on the day a person leaves their role, and rotation of any secrets they knew.

Authentication

Administration

• MFA is mandatory on every administrator and vendor account. Passkeys or hardware security keys when the service supports them, otherwise an authenticator app. SMS is accepted only when no other method exists.
• Passwords are unique, generated and stored in a password manager.

Users

• Passwords of at least 12 characters, and email verification at registration.
• Second factor: a one-time code sent by email when signing in from a new device and before each bank connection. Passkeys then become the primary sign-in method.
• Sessions limited to 30 days and revoked at sign-out and when the account is closed.

Encryption and key management

• In transit: TLS 1.2 or newer for all traffic between the applications and the server, and between the server and its vendors.
• At rest: the production database is stored on an encrypted volume (LUKS) whose key is itself encrypted with AWS KMS and never stored in plaintext on disk.
• Plaid tokens: additional application-level AES-256-GCM envelope encryption. Each data key is protected by AWS KMS and bound to the owner and the connection.
• Backups are encrypted before they leave the server.
• Master keys are held in AWS KMS in the ca-central-1 region (Montréal), with automatic annual rotation. The server’s AWS credentials allow only the required operations.
• Application secrets are rotated at least annually, and immediately after an incident or a departure.

Secrets management

• Secrets live in each environment’s private environment variables or in private files excluded from Git, readable only by their owner.
• A secret is never written in code, logs, screenshots, emails, tickets or chat.
• The security lead keeps an inventory of secrets: purpose, environment and date of last rotation.
• An exposed or suspected secret is revoked and replaced immediately, and handled as an incident.

Development and releases

• Every change is reviewed before it reaches production.
• Automated tests (unit, database, workspace isolation, main user flows), type checking and the build must pass before any deployment.
• Dependencies are locked with lockfiles and pinned versions.
• Input is validated on the server. Vendor notifications (webhooks) are verified by signature before processing.
• Long-lived vendor tokens stay on the server and are never sent to web or mobile clients.
• Development, staging and production environments are separate, with distinct secrets.

Vulnerability and patch management

• npm audit and vulnerability scanning (Trivy) in continuous integration, before every production release and every week.
• Automatic daily security updates for the server operating system (Ubuntu LTS). Kernel updates are applied at a planned restart.
• Workstations: automatic updates, full-disk encryption, automatic screen lock.

An actively exploited vulnerability is handled as an incident. The security lead keeps a list of production software (server operating system, Node.js, PostgreSQL, Coolify, major dependencies) with its end-of-support date, and plans migration before that date.

Logging and monitoring

• Application logs contain no secrets, tokens or bank content (amounts, merchants, descriptions).
• The audit log records only minimal metadata about exports, restores, erasures and sharing changes.
• Service availability and synchronization errors are monitored.
• Log retention follows the data retention and deletion policy.

Backups and continuity

• Daily backup of the production database, encrypted before upload to AWS S3 in Canada (ca-central-1).
• Retention of 30 days, enforced by automatic deletion.
• A restore test is performed and recorded every quarter.

Vendors and subprocessors

• Before using a vendor that processes personal information, the security lead assesses its security, processing location and contract.
• A privacy impact assessment precedes any communication of personal information outside Québec. A written agreement governs data use, confidentiality, incident notification and contract termination.
• The list of vendors and their processing locations is published in the privacy policy and reviewed annually.

Incident management

1. Detect and record the event in the incident register.
2. Contain: revoke affected access or secrets, isolate the system and, if needed, remove the affected bank connections.
3. Assess the risk of serious injury to the people concerned.
4. Notify the Commission d’accès à l’information du Québec and the people concerned without delay when the risk of serious injury is real, and notify vendors as required by agreements, including Plaid for any incident involving data received from Plaid.
5. Fix the root cause and document lessons learned.

Every confidentiality incident stays in the register for at least five years.

Physical and device security

• Servers are hosted by a provider in a data center in Montréal.
• Administration devices use full-disk encryption, automatic lock, an up-to-date operating system, and MFA on the device session when available.
• No production data is copied to a workstation, except temporarily when necessary, in encrypted form, and deleted afterwards.

Awareness and exceptions

The security lead reviews this policy and security best practices at least once a year. Anyone granted access reads this policy and agrees to follow it before receiving that access.

Any exception is written, justified, approved by the security lead, time-limited and recorded in the exceptions register.

Appendix: implementation status

Updated with every change. Controls marked “to do” will be in place before real bank data is accepted.