Security Policy

01 What this policy covers

This policy describes how CMYK Ink protects the systems that hold our clients' work: the platform, the files, the records, and the money trail. It applies to cmykink.io and every client-facing tool we run. It is written to be shared: if a partner, processor, or platform asks for our security posture, this page is the document.

Nothing here substitutes for the contract terms in a signed Master Services Agreement. Where the MSA is stricter, the MSA wins.

02 Client isolation

• Every client's records live in a database that enforces separation at the row level, not by convention. A client seat can only ever read and touch its own workspace, no matter what URL it navigates to.
• Before every release, automated cross-client tests run to prove that isolation holds. If a test shows one client's data leaking into another's view, the release does not ship.
• Staff accounts see only what their role requires. Executive seats are read-only: they can see aggregate numbers, never other clients' private files or documents.
• Internal planning notes on client events are staff-only and are never exposed through any client-facing view.

03 Role-based access

• Roles are stored in a protected database table, never in browser storage and never in a place a user could edit. Privileges are checked on the server, every request.
• Role changes are recorded in an append-only audit log: who changed what, when, for whom. Nobody can grant themselves a role, and a member cannot create or assign an administrator role.
• The highest administrative role has a database-level guard: a grant only succeeds when a current administrator of the same organization approves it. Recovery from a state with no administrators is an operator-controlled backend procedure, itself logged before it takes effect.
• Owners, executives, and anyone touching accounting use multi-factor authentication.

04 Uploads

• Every upload in the system passes through one guarded doorway. There is no side entrance.
• The guard checks file size per category, blocks executable and script file types, and inspects the first bytes of the file rather than trusting whatever the browser claims the file is.
• SVG files are sanitized before storage: scripts, event handlers, external references, and document-type tricks are stripped.
• What we don't have yet, stated plainly: there is no antivirus or malware scanning on uploads. Structurally valid but malicious PDFs or Office documents could pass the guard. Files in our storage should be treated as untrusted by anything that downloads them. Closing this gap needs an external scanning service on the write path, and it is a deliberate, tracked open item, not an oversight.

05 Sensitive numbers

• Account numbers, tax identifiers, and similar sensitive values are masked to the last four digits by default.
• Viewing a full value requires a recorded reason first. The reason is logged before the value is shown, so every full-number view has a name and a purpose attached.

06 Money controls

• Payment details can only be changed with confirmation codes sent to contacts already on file, never to an address or number supplied mid-conversation.
• Risk flags surface unusual changes for review before they take effect.
• Financial figures in reports come only from posted, approved ledger entries. Bank lines and processor records are evidence, not income, until a person approves them, so nothing is ever counted twice.

07 Email and messages

• Outbound email is sent through managed infrastructure with authenticated sending domains.
• Log records are redacted before they are written: tokens, credentials, signed links, and recipient lists never appear in plain text in our logs.
• Any new log line touching a credential or a recipient goes through the same redaction, enforced by the codebase's lint rules.

08 Where our systems live

Our platform runs on managed, reputable cloud infrastructure with encrypted connections throughout. Data at rest is stored by established cloud database and storage providers under their security programs. We don't operate our own physical servers.

09 If something goes wrong

When a security incident is suspected, we follow the same sequence every time:

• Contain: cut off the affected access immediately.
• Revoke: rotate the exposed credential or token, not just close the ticket.
• Scope: establish exactly what was touched and what wasn't, in writing.
• Notify: tell affected clients without hiding behind fine print, and meet Arizona's breach-notification requirement (A.R.S. § 18-552) where it applies.
• Record: log the incident, what we did, and what we changed so it can't repeat.

10 Retention

• Full client files: the engagement, plus 7 years.
• Compliance and verification records: engagement, plus 6 years.
• Marketing-consent records: 5 years after the last consent.
• Security logs and audit records: retained for the life of the platform, append-only.

We do not store patient medical records. Where work touches protected health information, a signed business-associate agreement comes before any data flows.

11 Your part

Security is a shared door. If you have an account with us: use a strong, unique password, turn on multi-factor authentication when offered, and tell us immediately if you see something that looks wrong, at hello@cmykink.io. If you report a suspected vulnerability or incident in good faith, we will treat it as help, not an attack.

12 Changes to this policy

We update this policy as our controls change. Material changes are flagged on the site. The version history of this policy is available on request, and a signed PDF copy can be provided to partners, processors, or platforms that require one.