Why Three Roles Aren't Enough: RBAC for Regulated Audit Ledgers

> Where to read this in context: the same role model is referenced from /audit (healthcare framing) and /audit/regulated-industries (SOX, GxP, GDPR, FedRAMP, ISO 27001 framing). The model does not change with the framework.

The Role Model Is Part of the Audit Trail

Most SaaS platforms ship with three roles: reader, contributor, and administrator. That model is fine when the worst-case failure is a deleted document. It is structurally insufficient when the system stores an immutable audit ledger that an external assessor will read — whether their cover page says HIPAA, SOX, GxP, GDPR, FedRAMP, or ISO 27001.

The reason is one principle: no one who can change data should also be able to alter — or hide — the evidence that they changed it. A three-role model concentrates both powers in the administrator, which is exactly the actor an external assessor is most interested in scrutinizing.

This post walks through where the three-role model breaks down for regulated audit ledgers, the seven-role model Magellan uses instead, and the explicit clauses each role is designed to satisfy across frameworks.

Where the Three-Role Model Breaks

Map the standard model against the actual control requirements and the gaps are immediate. The same gap is named in slightly different language by every regulator:

Notice the pattern: every gap is the same gap. One role — administrator — holds powers that compliance frameworks of every flavor require to be separated.

The Seven-Role Model

Magellan separates those concerns into seven roles, each with a narrow purpose. The point is not more roles for their own sake; it is that each role is the smallest set of capabilities a real human function actually needs.

Reader

Read mappings and schemas. No write access of any kind. No ledger access. This is the role for analysts and downstream consumers who need visibility but not editorial authority.

Contributor

Draft mappings and schema definitions. Cannot publish, cannot sign, cannot read the audit ledger. This corresponds to the day-to-day data-engineering function — most platform users live here.

Approver

Publishes contributor drafts, applies the second of two electronic signature components, and signs releases. An approver can see their *own* ledger entries (so they can confirm their signature was recorded), but cannot read the full ledger. This is the role that makes 21 CFR Part 11 §11.200, SOX change-management four-eyes, and ISO A.5.3 enforceable: a single contributor cannot release a mapping into production by themselves.

Auditor *(new vs. the standard model)*

Read-only on the full audit ledger. Cannot edit mappings. Cannot edit users. Cannot edit retention. Can export ledger ranges for internal or external review. This is the role designed against HIPAA §164.312(b), SOX SoD, FedRAMP AU-6, and ISO A.5.35 — the entity reviewing audit controls is structurally incapable of being audited *for* mapping changes, because they cannot make any.

Compliance Officer *(new)*

Everything Auditor has, plus the authority to apply attestation electronic signatures to ledger ranges (e.g., periodic review sign-off) and to configure retention policy. Like Auditor, has zero edit rights on mappings. This role is the named accountable party for §11.10(j) independent review, EU GMP Annex 11 §9 review, SOX management-assertion supporting evidence, and ISO A.5.35 independent review of information security.

Security Officer *(new)*

The named security role that HIPAA §164.308(a)(2), ISO A.5.2, and (where applicable) GDPR Art. 37 explicitly require. Manages user roles and grants — including grants of Auditor and Compliance Officer. Reads access-event ledger entries (logins, role changes, failed authorizations) but not mapping-content ledger entries. The separation here is deliberate: the person who controls *who can do what* should not also be the person reading the substantive audit trail. This is also the role that satisfies FedRAMP AC-6(7) ("Review of User Privileges") and SOX user-access-review ITGCs.

Administrator *(intentionally narrowed)*

In Magellan's model, Administrator is not the omnipotent super-role it usually is. Administrator manages platform configuration (integrations, environments, branding, non-security settings). Administrator cannot edit mappings, cannot read the audit ledger, and cannot grant Auditor / Compliance / Security Officer roles. That last constraint is what prevents a compromised admin account from quietly granting itself audit access — an attack pattern explicitly named in NIST AC-6(7) and in SOX SoD reviews.

The Capability Matrix

Two columns to look at carefully: Edit mappings and Read full ledger. No role has both. That single property is what makes the model defensible against §164.312(b), SOX SoD, FedRAMP AU-9, and ISO A.8.15.

What Lives in the Ledger Alongside the User ID

A role-aware audit model only works if the ledger remembers role state at the moment of action. Magellan writes, on every ledger entry:

• The actor's user identifier
• The actor's role at the time of action (not the role they hold now)
• The ULID-keyed decision identifier the action targeted (why ULIDs)
• The SHA-256 hash chain link to the previous entry
• An ISO 8601 UTC timestamp
• Where applicable, the second-component e-signature for §11.200 / SOX-four-eyes releases

This means a later role change cannot rewrite history. If a contributor was promoted to approver next quarter, last quarter's ledger still shows that they acted as a contributor — which is what every regulator needs to see.

Grants Are Themselves Ledger Entries

A subtle but important consequence of this model: every role grant is itself a ledger event. When a Security Officer grants Auditor access to a new compliance hire, that grant is written to the access-event ledger with the Security Officer's e-signature. There is no out-of-band "make this person an auditor" path. This closes the most common audit-system bypass — silently elevating an account, doing the work, then silently demoting it — and answers FedRAMP AC-6(9) ("Log Use of Privileged Functions") in one place.

What This Costs

Honest accounting: the seven-role model costs more than three roles in two ways.

1. Onboarding is slower. New hires need their function mapped to a role rather than dropped into "contributor." For most teams this is a one-time conversation with the Compliance Officer.

2. Some workflows take two people. Releases need a contributor *and* an approver. Periodic ledger sign-off needs an Auditor *and* a Compliance Officer's attestation. This is the whole point — single-actor workflows are exactly what §11.200, SOX four-eyes, and ISO A.5.3 are designed to prevent — but it does change tempo.

Both costs are visible. The cost of the three-role alternative is invisible until an assessor asks a question you cannot answer with the records you kept.

How to Adopt Without a Big-Bang Migration

Magellan's RBAC schema is additive. The recommended sequence:

1. Start with the existing three roles in place. Reader, Contributor, Administrator continue to work.

2. Introduce Security Officer first. Until this role exists, there is no one explicitly accountable for granting the audit roles. Identify the named individual per §164.308(a)(2), ISO A.5.2, or your equivalent.

3. Promote one Contributor to Approver per workflow. Begin enforcing two-actor releases on production mappings only. Drafts and dev environments remain single-actor.

4. Grant Auditor to internal compliance reviewers. They can begin sampling the ledger immediately.

5. Promote one Auditor to Compliance Officer for periodic attestation and retention policy.

6. Narrow Administrator last. Once the four new roles are populated, remove ledger-read and mapping-edit rights from Administrator. This is the change with the most blast radius and should be the last step, not the first.

Each step is reversible. None require ledger migration — the ledger format already records role-at-time-of-action.

Read More

• The ULID vs UUID post explains the identifier choice that lets ledger entries be ordered, range-scanned, and reconstructed without an external clock.
• Magellan's Audit Architecture, in One Page — the four primitives this role model rides on.
• Hash-Chain Integrity Deep Dive — what the SHA-256 chain protects.
• Audit Evidence Export and Attestation — the Compliance Officer's workflow.
• What an Auditor Actually Sees — the same five questions across frameworks.
• Why the Ledger Lives in the Same Container — how these seven roles map onto two Postgres roles.
• The Audit Ledger Brief (PDF) is the one-page technical summary of the ledger schema and hash chain.
• The white paper covers the full platform architecture, including the role model.

To see the role model applied against your own compliance posture, request a demo.

*Magellan AI Corporation — Charting every data connection.*