Security

Built into the platform, not bolted on.

Royalty data is sensitive. Creator PII, contract terms, payout details, and the math behind every payment all live inside CleaRoyalty. The platform is designed so that an attacker who breaks one thing can't reach everything, and so that nobody, including us, can quietly rewrite history.

Tenant isolation

Your data is separated at the database layer.

Every record in CleaRoyalty is keyed by tenant. The boundary is enforced where the data lives, not in application logic. A bug in our code can't return Tenant A's data to Tenant B because the database physically can't return records from a different partition than the one being queried. Authorization decisions happen once, at the gateway, and propagate from there.

Encryption

In transit, at rest, and per tenant.

TLS 1.3 in transit. AES-256 at rest. Sensitive fields like creator PII, royalty terms, payout details, and stored credentials are wrapped in an additional per-tenant encryption key — your data is encrypted with a key only your authorized services can use. Even if someone bypasses the application entirely and reads the database directly, they cannot read another tenant's sensitive fields with your key.

Access controls

Two-factor by default. Magic links for creators.

Tenant admins and platform admins authenticate with TOTP on every sign-in. Creators sign in with magic links scoped to their own statements. The platform itself never moves money — payable creation requires the tenant admin to approve the actual transfer in the connected payout system. Every access decision logs who, what, when, and from where.

Immutability

Published records cannot be quietly edited.

Once a statement is published, the original is preserved forever. Corrections create new versions that sit alongside the original. Once the contractual objection window closes, the period locks permanently — there is no override path inside CleaRoyalty, including for our own platform admins. A system where published numbers can be quietly edited is a system that invites suspicion. We made deception structurally impossible.

Records retention

Seven years, aligned with IRS guidance.

Statements, audit logs, and source data are retained for seven years from event date or tenant termination, whichever is later. The retention floor matches IRS recordkeeping guidance for tax-relevant business records and exceeds the longest plausible audit and dispute window. After the retention period, archives move to cold storage for one additional year before permanent deletion.

Audit log

Every action is on the record.

Reads, writes, approvals, overrides, downloads, support access — every event is attributed to the user (or system) that produced it, with a timestamp and source. The statement-level audit log is append-only at the database layer; it accepts new entries but rejects modifications to existing ones. Audit packages are exportable on demand and included in every offboarding archive.

Compliance posture

Designed for SOC 1 + SOC 2 Type II.

The architecture is built to support both attestations from day one. SOC 2 covers security and availability controls; SOC 1 covers controls over financial reporting, which is what your auditor needs when CleaRoyalty's royalty figures flow into your books. When customer demand justifies the formal audit, both are scoped together as a combined Type II report. GDPR-aligned: as a processor, we follow tenant erasure instructions where law permits, with the legal-obligation and legal-claims exemptions covering the contractual retention window.

Breach notification

Within 72 hours of discovery.

If a security event affects your data, we notify you within 72 hours of discovery, with what we know, what we don't know yet, and what we're doing about it. The notification commitment is part of every B2B agreement, not a courtesy. Follow-up communications continue until the event is resolved and the post-incident review is shared.

Support access

Logged. Read-only by default.

When CleaRoyalty engineers look at your data for support, every view and every action is attributed to the engineer who took it. Support tier is read-only, with no write path. Superadmin write actions exist for credential repair and tenant lifecycle, are explicit, are logged, and trigger an email to the affected tenant. The immutable layer (published statements, committed contract snapshots, audit log entries) refuses superadmin writes the same way it refuses every other actor's.

Responsible disclosure

Found something? We want to know.

Email security@clearoyalty.com with the details: what you found, how to reproduce it, and any impact you can demonstrate. Encrypt sensitive findings if you want to; we'll publish a PGP key when one is available. We acknowledge within two business days and aim to ship a fix or a clear timeline within fourteen.

We don't pursue legal action against good-faith research that follows responsible disclosure. We credit reporters publicly when issues are resolved, with your consent. Out of scope: denial-of-service, spam, social engineering of CleaRoyalty staff, and physical attacks. In scope: anything else that affects the confidentiality, integrity, or availability of tenant data.

Acknowledgment
Within 2 business days
Resolution target
Fix or timeline within 14 days