EDMS Permissions, SSO and External Access

EDMS access controls should answer whether this identity may perform this action on this document version, in this organization, project, site and lifecycle state. Single sign-on establishes an identity; it does not establish permission to read, export, change or approve a particular record.

This procedure produces a permission matrix and an acceptance record for a life-sciences document workflow. It includes employee, guest and service-account access, plus search and AI pathways that can disclose information without opening the original document.

The examples are an illustrative policy exercise, not a test of a commercial EDMS. Primary sources were checked on October 6, 2026. Adapt the proposed controls to your intended use, then verify them in your configured system before acceptance.

1. Fix the policy inputs before assigning roles

Start with the document owner, quality representative where applicable, identity administrator and system owner. Obtain the approved lifecycle, organizational boundaries, project/site memberships and list of interfaces. Identify who may authorize access and who verifies that the configured result matches that authorization.

Record the EDMS release and configuration, identity provider, provisioning method and connected search, AI or export services. An unanswered interface question is an unresolved dependency, not evidence that the route is secure.

For each request, the policy needs six inputs:

Use controlled values from the systems that own them. Do not create a separate spreadsheet vocabulary that silently treats “approved,” “released” and “effective” as interchangeable. Define multi-site and cross-project documents explicitly; a blank site must not automatically mean every site.

NIST's attribute-based access-control model evaluates characteristics of the subject, object, requested operation and relevant environment against policy. That is a useful design framework for these inputs, not a regulatory mandate to buy a particular architecture. NIST SP 800-162, January 2014 with August 2019 updates.

Write a decision rule in plain language: permit only an explicitly authorized action when all required scope and state conditions are satisfied; otherwise deny. A missing organization, unknown membership or unrecognized state produces no grant. Escalate the data problem to its owner rather than filling it with a permissive default.

2. Build a matrix that describes behavior

The following matrix is a starting policy for the fictional Alpha organization. Employee roles require active Alpha membership and the listed document's project and site assignment. Guest and service grants use separately approved, narrowly specified scopes. Every permission not stated is denied.

These are local example rules. In particular, the example's prohibition on self-approval is a segregation choice, not a claim that every EDMS document has a universal two-person approval requirement.

Separate actions that the product may bundle. “Read” might include downloading the original file in one product and only viewing a rendition in another. Define your intended meaning, ask what the software actually enforces and test it. A policy that prohibits export is not proof that an authorized reader cannot photograph or copy displayed information.

A person may hold multiple roles. Specify how grants combine and which restrictions prevail. In this example, an Author who is also an Approver still cannot approve their own revision. A Reader grant in Atlas does not create an Author grant in another project. Approval permission also does not automatically include making a document effective; assign that transition separately if your lifecycle uses it.

For administrators, document any technical ability to access content or alter permissions. Where elevated access is necessary, define its authorization, duration, attributable use and independent review. An administrator account should not be used as the ordinary approver's identity merely because it can make the workflow proceed.

For the surrounding controlled lifecycle, see the QMS document-control guide.

3. Make SSO and account changes reach the EDMS

SSO answers a different question from provisioning. A successful identity-provider login does not show that the EDMS has the correct current project assignment. Record how a new user receives permissions, how changed memberships propagate and how a disabled account loses access through each connected route.

Run a joiner, mover and leaver exercise:

1. Joiner: approve the intended role and scope, provision the account, then prove permitted access and one neighboring denied scope. A user awaiting approval should not receive a broad default role.
2. Mover: remove the previous assignment as well as adding the new one. Verify old bookmarks, saved searches, queued jobs and any active sessions against the changed policy.
3. Leaver: disable the relevant identities and credentials, then verify the EDMS, interfaces and outstanding delivery routes no longer permit access. Preserve historical attribution to the departed person.

Define the required revocation behavior and the maximum accepted propagation delay for each route before testing. Do not invent a universal “instant” value. Record the change timestamp, observed enforcement timestamp and any controls used during the interval. If the product cannot meet the approved requirement, change the design or hold acceptance.

Session behavior deserves its own evidence. OWASP recommends renewing session identifiers after privilege changes and invalidating the previous identifiers. Verify your supplier's actual session/token handling rather than assuming an identity-provider change terminates everything downstream. OWASP Session Management Cheat Sheet.

Test a missing group claim, failed provisioning update and ambiguous group mapping. An interface that cannot establish authorization should withhold the affected access and report the failure. Do not silently interpret “group service unavailable” as “all employees.” Distinguish an authoritative removal from a transient synchronization error in the operational record, while keeping the unresolved grant closed.

4. Give guests and services separate operating rules

A guest grant needs a named sponsor, verified external identity, approved record list, allowed actions, start/end timestamps with time zone and renewal owner. In this example, access is allowed at or after the start and strictly before the end. At the exact expiry timestamp, the grant is no longer active.

Invite a guest to a specific collaboration scope rather than inheriting a whole department's permissions. Test whether attachments, historical versions and related records follow the intended sharing decision. Sharing one version must not accidentally reveal an unrelated attachment or a later confidential draft.

A service account needs a business owner, technical owner, job purpose, accessible collection, permitted operations and credential lifecycle. Determine whether it acts independently or on behalf of a user. If it acts on behalf of a user, its broad technical connection must not erase the user's narrower authorization.

Include scheduled jobs in the review. A job created while its requester was authorized may run after reassignment or departure. Define which current identity and grant authorize execution and delivery, and test both points. A missing owner or expired credential-renewal decision is a reason to stop the affected integration, not to substitute a shared human account.

5. Check every route that reveals or changes information

A disabled button is not proof of denied access. OWASP recommends least privilege, denial by default and authorization checks on every request, including requests outside the visible user interface. OWASP Authorization Cheat Sheet.

Create one acceptance row for each relevant route:

For a mixed export containing allowed and denied records, choose a documented behavior: reject the request or produce an explicitly identified authorized subset. Do not label a partial export “complete.” For a policy-service failure, withhold the affected operation; an unknown decision is different from a known record-level denial.

For AI retrieval, document where source permissions attach to indexed chunks and how changes propagate to indexes and response caches. Authorization must occur before restricted content reaches the model; instructing the model not to reveal it is not the enforcement boundary. OWASP's RAG guidance specifically addresses permissions at retrieval time and access-control inheritance into chunks. OWASP RAG Security Cheat Sheet.

Use a distinctive synthetic phrase in a forbidden fixture. Ask for it directly and through related questions, but also inspect retrieval evidence: an answer that happens to omit the phrase does not prove the model never received it. Repeat after removing the user's source permission. A previously cached authorized answer must not become a continuing delivery route for that now-unauthorized user.

6. Execute the permission acceptance worksheet

Copy this fixture into a nonproduction environment with synthetic documents. Record policy revision, EDMS configuration, interface versions, tester and execution time. The expected decisions below follow the illustrative matrix; observed product results must be supplied by your team.

Fixture records all belong to Alpha/Atlas/North: D101 revision 1 is Draft, D102 revision 1 is Pending approval, D103 revision 2 is Effective and D104 revision 1 is approved but not yet effective. Create a separate Beta/D103 to test colliding local IDs across organizations. Give Alice the Author assignment for D101 and D102, Omar the Approver task for D102, and Ruth Reader access to Alpha/Atlas/North. These employees have active membership in that scope. Guest Gia has an explicit D103 grant from 09:00 inclusive to 10:00 exclusive, UTC on the test date. The export service is limited to Alpha/Atlas/North Effective records; it has no Beta grant.

For each row capture identity, membership snapshot, document namespace/version/state, action, pathway, timestamp, expected result, observed result, evidence reference, owner and disposition. Expand rows with multiple actions into separate execution records. Capture grants and denials; testing only that unauthorized users are blocked misses a configuration that blocks everyone.

Use four dispositions: pass, fail, unknown and justified not applicable. A pass requires evidence matching the expectation. A fail is observed contradiction. Unknown means missing execution or inconclusive evidence. Not applicable requires an authorized reason and does not apply merely because a difficult interface was omitted. Required failures and unknowns block acceptance of that scope.

For a worked A10 variation, let approved policy POL-02 require denial through every listed route no later than five minutes after removal. This is a fictional local threshold. Identity record ID-07 removes Ruth's Atlas membership at 14:00 UTC. At 14:05, direct-request evidence WEB-08 shows denial, search evidence SEARCH-08 shows no protected results, and AI evidence AI-08 shows delivery of a previously cached D103 answer. The route results are Pass, Pass and Fail; two passing checks do not average away the third. The system owner holds the AI route and investigates cache authorization before repeating the permitted and revoked-user cases. If AI-08 is missing instead, that route is Unknown. A statement that “SSO removal succeeded” supplies neither execution evidence nor a pass for the AI route.

7. Resolve a failure at its enforcement point

Consider a documentary failure case: Ruth's direct request for Draft D101 is denied, but an AI answer includes D101's synthetic restricted phrase. The document-page control passed; the end-to-end confidentiality requirement failed.

Investigate the retrieval trace, acting identity, chunk permissions and cache provenance. If the connector retrieved all Alpha documents using its service identity without Ruth's scope, the corrective boundary is the retrieval authorization design. Merely removing the phrase from the answer or adding a prompt instruction does not correct that access path.

Hold that AI route until the cause is corrected and retested. Repeat both the allowed D103 request and forbidden D101 request, then the membership-removal case. Review adjacent search/export connectors for the same overbroad identity pattern. This is a hypothetical diagnostic sequence, not evidence of a defect in a named vendor.

If retrieval traces are unavailable, the result remains unknown; do not replace missing evidence with a successful-looking answer. Similarly, a zero-result search is insufficient if a preview URL still serves restricted content.

8. Connect the evidence to the applicable record controls

Where Part 11 applies to a closed system, 21 CFR 11.10(d) addresses authorized access and 11.10(g) addresses authority checks for permitted operations. Applicability depends on the electronic records and underlying requirements, not the EDMS label alone. 21 CFR 11.10, FDA's August 2003 scope and application guidance.

For computerized systems used in GMP activities within its scope, Annex 11 section 12 addresses access restrictions and recording creation, change and cancellation of access authorizations. The Commission's current index lists the January 2011 revision. Annex 11, revision 1, EudraLex current index.

Attach your approved policy, configured matrix, executed evidence and resolved exceptions to the appropriate change or validation record. This worksheet supports that work; it does not establish complete compliance or replace the wider computerized-system validation process.

Release the accepted access scope only when the designated owners approve the evidence. Repeat affected checks after role-model changes, new interfaces, document-state changes or identity-integration changes. Set an access-review cadence from the documented risks and organizational procedure rather than assuming one universal interval.

If you are evaluating a regulatory-document workflow with Assyro, bring the completed permission matrix to a discussion. Use it to establish the required boundaries and evidence for the proposed workflow before accepting any product capability claim.