SoD, delegation, and deny grants

Access security rests on three mechanisms, each covered below in its own section: separation of duties (SoD), delegation, and deny grants.

Separation of duties (SoD)

Separation of duties does not allow one person to combine permissions that, by regulation, should belong to different people. Classic pairs:

• whoever enters data (data.enter) should not verify it (data.sdv.verify);
• the author of design edits (studyversion.update) should not approve them themselves (studyversion.approve);
• whoever grants access (access.grant) is kept in check when this is combined with editing data.

Each SoD rule is data (a pair of conflicting permissions + a policy), configurable to your sponsor’s regulations. There are two policies:

Policy	What the system does
block	strictly rejects the grant: the restriction cannot be bypassed; you need to change the scope, the role, or the permission set
warn	performs the operation but warns about the conflict; the fact of the combination is recorded in the audit trail

When an SoD warning fires

The check happens when a grant is issued or a role is assigned — by the principal’s effective permissions, not by the composition of a single role. That is why a conflict is caught even when it is formed from two individually “clean” roles: otherwise SoD would be trivially bypassable. Under the warn policy, you will see “Created, but there are SoD warnings” with the conflict spelled out; under block — “The combination is prohibited by the SoD policy (block).”

SoD on approval acts — a policy, not a constant

The “approved by someone other than the author” rule for approval acts (a design version, a translation bundle) is controlled by the “Strict separation of duties on approvals” setting (core.sod.strict_approvals) — for the whole tenant or for a single study (Admin → Settings).

• Default — lenient: the author may approve their own work; the system always marks the fact of self-approval in the audit trail (self_approved) — the trace does not depend on the policy.
• Strict mode: a design or a translation can only be approved by a different person. If the very author tries to approve it, the system tells you directly — “Approval must be done by a different user with the studyversion.approve permission” — with a “Configure access” link.

Strict mode is appropriate when the sponsor’s regulations or your QMS require it; lenient — for teams where the process does not provide a second pair of hands. The issuance-time pair studyversion.update × studyversion.approve follows the same policy: in lenient mode the grant goes through with a warning (otherwise the approval permission could not even be granted to the author). The other pairs — above all data.enter × data.sdv.verify — do not depend on this setting.

Small organizations: a documented exception

In strict mode, a second pair of hands for approval may simply not exist — say, in an investigator-initiated trial or in a one- or two-person CRO (if strict mode is not required at all, simply leave it off — see the policy above). Data-integrity guidance (PIC/S PI 041, MHRA GxP Data Integrity) allows departing from separation of duties in such cases — but documented and authorized, never silent.

In X7 Insight the carrier of such an exception is an ordinary grant of a dedicated permission:

• studyversion.self_approve — the author of a design version may approve it themselves;
• translation.self_approve — a translator may approve their own translation.

The issuance rules are strict and cannot be bypassed:

• it cannot be granted to oneself — the exception is authorized by a different person (in a one-person organization — a sponsor representative, a QA consultant, or a platform administrator): the four-eyes principle is not abolished, it moves from the act of approval to the act of authorization;
• an expiry is mandatory (valid_to) — there are no open-ended exceptions; the door closes by itself when the term runs out;
• a reason is mandatory — reference the risk assessment in your QMS;
• it cannot be put into a role — the permission is personal and is issued only as a direct grant.

What happens next: an author holding an active exception approves their own version, and the system marks the fact of self-approval in the audit trail (self_approved) — an inspector will see it first. The blocking pair studyversion.update × studyversion.approve is downgraded to a warning while the exception is active: the permissions are issued, the conflict stays visible.

What is never relaxed

The data.enter × data.sdv.verify pair has no exceptions: source data verification (SDV) is a check against the source by a second person. Someone verifying their own entry is not performing SDV. In strict mode, the rule that a version with an unrecorded author cannot be approved is not relaxed either.

Delegation (covering for a colleague)

Delegation is when you temporarily transfer your own permissions to a stand-in (for example, a monitor goes on vacation and a colleague picks up their sites). Delegation follows strict rules:

• you can transfer only a subset of your own effective permissions (⊆ your permissions) and only into a subset of your scope;
• depth is one level: the person you delegated to cannot delegate further;
• the term of delegation does not exceed the term of your own permissions;
• when your permissions are revoked or expire, the delegated ones are automatically revoked in a cascade.

1. In the Admin → Access area, create a temporary assignment of the same role for the stand-in, on the same (or a narrower) scope.

2. Set the “from — to” dates — the coverage applies exactly within this window.

3. When the vacation ends, access ceases on its own (or is revoked manually).

A personal signature is not delegated

Delegation transfers permissions but not personal responsibility. The permission to sign can be transferred, but the electronic signature itself is always applied by a specific person with re-authentication. “Signing on a colleague’s behalf” is impossible under any delegation.

Deny grants: a denial always wins

A deny grant is a pinpoint denial of a specific permission to a specific principal in a specific scope. Its distinguishing property: a deny wins over any grant on the path. Even if a person has a broad role that gives this permission, a pinpoint deny overrides it.

Deny grants are a surgical tool for exceptions: a conflict of interest, an internal investigation, a temporary restriction. Example: deny one coordinator data.update on one site, without touching their role and without affecting the other sites.

1. Open the person’s card under Admin → Users and click “Grant permission.”

2. Specify the permission and where it applies, and in the “Effect” field choose “Deny — a deny beats any allow.”

3. Confirm. The system warns: “A deny beats every allow on the path: a pinpoint exception that no role can override.”

How an access decision is read

The access engine is deterministic and explainable. For any request it collects all applicable grants by scope prefixes and decides as follows: if there is at least one deny → denied; otherwise if there is at least one grant → allowed; otherwise denied by default (default deny). The order of granting does not matter — the result is always the same.

Debug denies via 'Check access'

Pinpoint denies are easy to forget, and then “missing” access looks mysterious. Do not guess: the “Check access” tool (Admin → Users) will show the outcome for each permission and the source of the decision — including the winning deny. See Managing access.