Permission-aware RAG for ISO 27001 access control

Permission-aware RAG for ISO 27001 access control starts with the source documents

A RAG assistant meets the access restriction expectations of ISO/IEC 27001:2022 only if it inherits each source document's permissions at retrieval time, not just at the login screen. If a user cannot open a restricted file in the document store, the assistant must not retrieve its chunks, quote them or summarize them for that user. For an ISMS owner, the question to answer is simple: can you show that a finance user never receives an answer built from an HR file they cannot open? Annex A control A.8.3, Information access restriction, asks that access to information is restricted in line with the topic-specific access control policy. Control A.5.15, Access control, asks for rules that govern physical and logical access, based on business and information security requirements. Both are written in general terms, so the design choices that satisfy them sit with you and your implementation partner.

Treat the source system as the authority. Before indexing, record each document's owner, classification and access groups from the repository, then carry those attributes into the vector store as metadata on every chunk. At query time, the retrieval layer should apply a filter for the caller's identity and groups before similarity ranking, so the model never sees unauthorized text. Confirm how your chosen stack handles this: Open WebUI documents role-based access control with groups and per-resource permissions, while Dify's workspace and app roles are a different boundary. Ask whether the retriever can filter on metadata natively, and test it with a dedicated set of restricted documents and test accounts, because a filter that works in the interface may not apply to API calls.

Two boundaries matter for the audit file, and neither is a certification. ISO does not certify organizations; accredited certification bodies do that work against the standard. DeployOpen plans, implements and tests the access controls, and prepares the control descriptions, configuration records, test results and access review evidence that your certification body will examine. DeployOpen does not issue audit reports or certificates. Confirm with your certification body which evidence it expects for A.8.3 and A.5.15 before the build starts, and agree in writing which controls, tests and deliverables are in scope.

How A.8.3 and A.5.15 map to retrieval filtering and configuration

This table maps the two access control Annex A controls to the retrieval functions and platform settings that enforce them in a self-hosted RAG assistant. Read each row as a requirement, the function that carries it, and the evidence an assessor will expect to see. The main takeaway is that the control is only met when filtering happens before ranking and is tested against the prompt, not when a login screen exists.

Requirement or function	What it must do in the RAG pipeline	Configuration and evidence to keep
A.8.3 Information access restriction	Restricts access to indexed content in line with the topic-specific access control policy, so the assistant cannot surface documents the user could not open at source.	Written policy reference, mapping of each knowledge collection to an owner and classification, and a record of who approved each collection.
A.5.15 Access control (rules for logical access)	Establishes and applies rules for access to information based on business and security needs, covering the retrieval layer as well as the source repositories.	Access rule set for the assistant, documented as a rule for retrieval, with review dates and the business owner who signed it off.
Source ACL capture at ingestion	Reads owner and permission data from each source system (file share, wiki, ticketing) and stores it with every chunk, so permissions travel with the content.	Connector configuration, sample records showing ACL fields on chunks, and a note on which source permissions cannot be read and how they are handled.
Group sync from the identity provider	Keeps user-to-group membership current so filters reflect today's access, including removals, not the state at the last indexing run.	Sync schedule, SCIM or OIDC claim mapping, and logs showing a removed user lost access within the agreed sync interval.
Per-query permission filtering before ranking	Applies the user's groups and identity as a mandatory filter in the vector and keyword search, so restricted chunks are excluded before reranking and never scored.	Retrieval query logs showing the filter values, and a default-deny rule if the user has no mapped groups.
Open WebUI groups and per-resource permissions	Limits which users and groups can open each knowledge collection, model or tool. Confirm that collection-level permissions are enforced by the retrieval call, not only by the user interface.	Group list, per-knowledge-base access grants, and a test where a user outside the group asks for content from that collection.
Dify workspace and SSO scopes	Separates workspace access from web app access and maps identity provider groups to workspaces. The Community edition is limited to a single workspace, so confirm whether the required separation needs Enterprise.	SSO protocol and identity provider configuration, workspace membership list, and documented scope for each web app.
Vector metadata fields for owner and classification	Stores owner, source group, classification label and source system ID as filterable fields on each chunk and embedding record, so filters are evaluated in the vector store.	Index schema, field list with allowed values, and confirmation that the vector database supports pre-filtering on these fields in the chosen version.
Tests that a restricted chunk never reaches the prompt	Runs negative tests with users who lack access and checks the retrieved context and the final prompt, not only the answer text. This is the evidence that the control works.	Test cases with expected denials, stored results per release, and prompt traces kept in the organization's own storage.

Why a RAG assistant leaks restricted content when permissions are checked only at the chat screen

An assistant that checks permissions only when the chat window opens will leak restricted content, because the restriction lives in the source system and the index has already copied the content out of it. Ingestion splits each file into chunks, turns those chunks into embeddings and writes both into a vector store. Once that happens, the text of a restricted file sits in a shared index, and a retrieval query can return a passage from it to any user whose question happens to match. Illustratively, a salary band paragraph from an HR file that only the HR team can open could surface as the top citation for a question from a regional manager, even though that manager would be refused if they opened the file directly. Under ISO/IEC 27001:2022 Annex A control A.8.3 Information access restriction, access to information must follow the organization's access control policy, so the index itself has to be treated as a copy that needs the same restriction as the source.

Three common designs bypass source ACLs even when the chat screen looks correct. The first is the assistant's service account: if the connector reads every document with a broad service identity, retrieval sees everything and the user's identity is never tested. The second is shared collections, where many files are merged into one knowledge base for convenience and the source folder structure and group membership are lost during ingestion. The third is cached answers: a response generated for a privileged user can be stored and served to a later user with the same question, skipping retrieval entirely. Each of these is a design decision to make early. Confirm with the implementation partner which identity the connector uses when it reads source systems, whether collections map one-to-one to source permission boundaries, and whether answer caching is off or keyed to the requesting user and their current access. Platform features such as Open WebUI's per-resource permissions and SCIM group provisioning help, but whether they enforce source-level ACLs on indexed chunks is a question to verify in the deployed stack, not assume.

Which retrieval filtering design fits which access model

This design creates a separate index or collection for each user or group, so retrieval only searches content that the identity was already allowed to read when the index was built. It is the simplest model to explain to an auditor because the boundary is physical: a query cannot reach a collection the user has no access to. The cost is duplication. A document shared by many groups is embedded and stored once per collection, so storage and embedding compute grow with the number of audiences rather than the size of the corpus.

Indexing cost: Shared documents are parsed and embedded repeatedly, and every new group adds a full copy of its slice of the corpus.
Permission freshness: A group membership change requires rebuilding or reassigning the affected collections, so access changes lag until that job completes.
Operational complexity: Index lifecycle, deletion and re-indexing run per collection, which multiplies monitoring and failure cases as the number of groups grows.
Platform fit: Confirm whether the platform you choose supports collection-level access control natively or whether your team must enforce it in the application layer.

Before committing, ask the implementation partner how many distinct audiences exist, how often memberships change and whether the duplication cost is acceptable at that scale.

Self-hosted platforms that can enforce permission-aware retrieval

A RAG assistant inherits its access rules from the platform that retrieves the content, so the platform choice decides whether source permissions survive into answers. The candidates below differ in how they handle users, groups, workspaces and vector storage, and none should be assumed to filter by source document permissions until the team has tested it.

Open WebUI role and group controls

Open WebUI offers role-based access control with groups and per-resource permissions, SSO through OIDC and LDAP, and SCIM 2.0 user and group provisioning, so group membership can follow the identity provider. Confirm whether knowledge collections can be scoped to the same groups that govern the source systems, because group-level access to a collection is not the same as document-level filtering. Its retrieval layer supports 13 vector databases, including PGVector and Qdrant, with hybrid search and reranking. Test per-document filtering before relying on it for ISO 27001 controls.

Open WebUI licensing and scale

Open WebUI is distributed under the Open WebUI License, whose branding clause applies to deployments above 50 users in any rolling 30-day period unless the operator holds an enterprise license or written permission. Multi-replica deployments need PostgreSQL instead of SQLite, plus Redis for shared state and shared file storage so uploads and knowledge stay reachable from every replica. Ask the vendor or your counsel how the license applies to your user count and whether branding must remain visible.

Dify workspace and secret management

Dify Community edition is limited to a single workspace, while Enterprise adds SSO, multiple workspaces and advanced security. Permission boundaries for knowledge bases therefore depend on the edition and on how applications are split across workspaces. Protect the SECRET_KEY, since changing it after deployment logs out all users, and confirm where workspace encryption keys are stored. Dify's license also forbids operating a multi-tenant service from its source code without written authorization, which matters if the assistant serves customers.

RAGFlow under Apache-2.0

RAGFlow is an open source retrieval-augmented generation engine licensed under Apache-2.0, which carries no branding or user-count restriction. Its document parsing and retrieval are the components most likely to matter for permission-aware search, so review how it stores document metadata and whether it can attach access attributes to chunks at ingestion. Confirm whether it filters retrieval by user or group identity, rather than only restricting who can open the knowledge base in the interface.

AnythingLLM workspaces and access

AnythingLLM is licensed under MIT and organizes documents into workspaces with user roles. Workspaces are a coarse boundary, so the design question is whether one workspace can hold documents with different classifications and whether a user outside a permitted group can receive chunks from them. Test a document that a user cannot open in the source system and confirm it never appears in a citation. Record the release tested, because role and workspace behavior changes between versions.

Self-hosted vector store choice

The vector store holds chunks and their metadata, so it is where access attributes must be stored and enforced at query time. pgvector keeps vectors in PostgreSQL, which lets teams reuse existing database backup, encryption and role controls. Qdrant offers payload filtering on indexed fields and runs as a separate service. Either option is self-hosted and keeps document-derived vectors in your own infrastructure. Confirm that filters are applied inside the vector query, not after results are returned to the model.

How the identity provider, connectors, vector store and model fit together

The permission check has to sit in the retrieval step, before any chunk is ranked, reranked or placed in a prompt. The request path starts when a user signs in through OIDC or SAML against the organization's identity provider. The assistant then resolves that user's group membership and passes the identifiers to the retriever as a mandatory metadata filter on the vector store. Only chunks whose stored access control list (ACL) matches those groups enter hybrid search and cross-encoder reranking, and only the surviving chunks are sent to the model. Open WebUI documents OIDC and LDAP sign-in, group-based role-based access control and per-resource permissions, but whether its knowledge collections can enforce document-level ACLs from a source system is a point to confirm with your implementation partner and test with a non-privileged account, not assume.

The connector side decides whether that filter has anything to work with. At ingestion, each connector should capture the source system's permissions for every file (users, groups, inherited folder rights and deny rules) and write them to chunk metadata alongside the document identifier. Permissions change more often than content, so the sync design must re-read ACLs on its own schedule and remove access promptly when a user leaves a group, not only when the document text changes. Ask for the sync cadence in writing, the behavior when a source system is unreachable (fail closed is the safe default), and how revoked access is purged from cached embeddings and the reranker's working set.

Logging and tracing sit around this path rather than inside it. An AI gateway such as LiteLLM can record model calls and enforce guardrails between the assistant and the model provider, and Langfuse or Phoenix can record traces that show which chunks were retrieved for each answer. Be aware that Arize Phoenix is licensed under the Elastic License 2.0, which prohibits providing the software to third parties as a hosted or managed service, so confirm that your deployment model stays within that limit. Trace stores hold prompts, retrieved text and user identifiers, so they inherit the same access restrictions as the source documents and should be reviewed under the same retention rules.

Evidence auditors ask for and which component produces it

This table maps the evidence an assessor is likely to request for a permission-aware RAG assistant to the component that produces it. Read each row as a question to answer before the audit, and confirm log retention against your own information security policy and any applicable legal retention requirements.

Evidence item	What it shows	Component that produces it
Access control policy mapped to A.5.15 and A.8.3	Rules for who may reach which documents, and how the assistant inherits them	Organization's policy documents, reviewed against the assistant's retrieval design
Group and role exports from the identity provider	Which users belong to which groups at a given date	Identity provider (such as Entra ID or Okta), exported and retained with timestamps
Group and role mappings inside the assistant	How identity provider groups translate into assistant roles and collection permissions	Open WebUI or Dify admin configuration, SCIM or SSO sync records
ACL metadata stored per chunk	Which source permissions travel with each indexed chunk	Vector store metadata (for example, Weaviate, Qdrant or pgvector payload fields)
Restricted-document retrieval test results	Proof that unauthorized users do not receive restricted chunks or citations	Test scripts and results, stored with the evaluation harness and dated per release
Permission change sync logs	When source ACL changes reached the index and how long that took	Connector or ingestion pipeline logs, plus re-index job records
Query and retrieval logs	Who asked what, which chunks were returned, and which were filtered out	Open WebUI or Dify admin logs, gateway logs, and Langfuse traces where deployed
Access review records	Periodic confirmation that collection access still matches business need	Signed review records from the data owner, compared against identity provider exports

Questions buyers ask before hiring help with permission-aware RAG

Does ISO 27001 certification require a RAG assistant at all?

No. ISO/IEC 27001:2022 does not require any particular application, including a RAG assistant. It requires an information security management system (ISMS) that covers the organization's information assets and the controls it selects. If you deploy an assistant that answers from internal documents, that assistant becomes an asset inside the ISMS scope, and the controls that apply to information access, such as A.5.15 Access control and A.8.3 Information access restriction, apply to it. Your certification body will test whether those controls work as you describe them, so the design needs to be written down and provable. Confirm the boundary and asset list with your certification body before you start.

What drives the cost and effort of permission-aware RAG?

Four factors drive most of the effort:

Number of sources. Each connector to a file share, wiki, document management system or ticketing tool needs its own parsing, permission mapping and sync job.
ACL complexity. Nested groups, inherited folder permissions, document-level exceptions and sensitivity labels take more design and more test cases than a flat model.
Identity integration. Mapping users and groups from your directory into the assistant and keeping them current depends on how your identity provider is set up and who owns it.
Testing. Retrieval tests that prove a user never sees a chunk they are not entitled to are the largest part of the evidence work.

Costs are one-time for design, connectors and testing, and recurring for re-indexing, permission sync, model hosting and periodic re-testing. Ask any partner for a quote that separates these lines and states the source systems in scope.

How long does a permission-aware RAG implementation take?

The duration depends on the scope you agree, so there is no fixed figure that applies to every organization. The main variables are the number of source systems, how cleanly permissions are defined in each one, the state of your identity groups, and how many test cases your access policy requires. DeployOpen works on fixed-scope engagements, so the timeline, deliverables and acceptance tests are written into the agreement before work starts. Ask for the phases, the dependencies on your teams, and the acceptance criteria for retrieval filtering, and check that each phase has a named owner.

What does our team need to provide before the work starts?

You will need four groups of people and material:

Identity owners who can confirm how users, groups and nested memberships are defined and who can provide read access to the directory for the integration.
An access control policy that states who may see which classes of information, which the assistant will implement and which an auditor will check.
Document owners for each source who can confirm which folders or sites are authoritative, which are restricted, and how permissions are inherited.
Test accounts representing each role, including users who should be denied access to specific documents, so retrieval filtering can be tested with evidence.

Missing any of these typically extends discovery. Confirm the list and the decision owners in the written scope.

Can our own team build permission-aware RAG without a partner?

Yes, if you have the internal skills and capacity. The work spans platform engineering (deploying and operating the assistant and its vector database), identity engineering (group mapping and sync), data engineering (parsing and permission-aware indexing), and security testing (retrieval and answer tests with evidence). Many teams have strong engineers in one or two of these areas but not all four, and the gap usually appears in permission sync and test design. A partner is worth considering when the internal team cannot staff those gaps, when the deadline for an audit is fixed, or when you need an independent test of the design. Whichever route you choose, the operating ownership and the evidence must stay with your organization.

How do the license limits of Dify or Open WebUI affect the design?

The license determines what you can deploy and how you can brand or distribute it, so check it before you choose the platform. Open WebUI is distributed under the Open WebUI License, whose branding clause applies to deployments above 50 end users in any rolling 30-day period unless you hold an enterprise license or written permission. Dify's community edition is limited to a single workspace, and the Dify license forbids using the source code to run a multi-tenant environment without written authorization. For an internal assistant with separate permission groups, the design question is whether you need multiple workspaces, which points toward the Enterprise edition, or whether group-based filtering inside one instance is enough. Ask your legal team to review the current license text and confirm the limits against your user count and architecture.

How do we know the assistant will not leak restricted content?

You cannot rely on the model to hide content it has been given, so the protection must sit in retrieval. The assistant should check the caller's identity and entitlements against the source permissions before it searches, and it should filter results at query time rather than after generation. Test this with the accounts defined in your policy, including attempts to reach restricted documents through paraphrased questions, and keep the test results as evidence. Add logging of who asked what and which documents were returned, because your auditor will ask how you know the control works over time. Ask any partner how they test this, what they record, and how they re-run the tests after a connector or group change.

Which evidence will an ISO 27001 auditor ask for from this assistant?

Auditors typically ask for the documented access control policy, the asset entry for the assistant, the mapping from source permissions to retrieval filters, and evidence that filters work. They also look for records of access reviews, change records when connectors or groups change, and logs that show retrieval decisions. Standards bodies do not issue checklists for individual applications, so confirm the expected evidence with your certification body and your auditor. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Those decisions remain with the independent certification body.

What tooling alone does not satisfy

A permission-aware assistant enforces access at retrieval time, but it cannot decide who should have access or prove that the control works. The cards below mark the gaps that remain after the platform is installed and the connectors are configured.

Policy and risk assessment stay human

The access control policy that A.5.15 and A.8.3 point to must be written, approved and owned by the organization, and the risk assessment that justifies it must be performed by its people. Software enforces the rules it is given. It does not decide which document classes deserve restriction or which business roles should see them. Before build work starts, confirm who signs the topic-specific access control policy and where the risk assessment records are kept.

Certification comes from accredited bodies

ISO does not certify organizations. Accredited certification bodies do, and they audit against ISO/IEC 17021-1 together with ISO/IEC 27006-1. DeployOpen prepares the system, the configuration and the evidence for that assessment, but it does not issue audit reports, attestations or certificates. Ask any implementation partner, including DeployOpen, to state this boundary in writing and to name the certification body that will assess the scope.

Source permissions may already be wrong

The assistant copies the permissions it finds in SharePoint, file shares, wikis or ticketing tools. If those permissions are overly broad, inherited by accident or stale, the index will reproduce the exposure, and answers will reveal content to people who should never see it. Before indexing, run an access review on each source collection and record the exceptions. Retrieval filtering only narrows access to what the source already allows.

Offboarding needs a defined sync interval

A leaver who loses source access must also lose assistant access, and the gap between those two events is a control in its own right. Define how often group membership and document permissions are synchronized into the retrieval layer, and what happens to cached results, open sessions and existing embeddings when a user is removed. Document the interval as a control and test it with a named leaver.

Map to the 2022 edition only

The transition from ISO/IEC 27001:2013 to the 2022 edition ended, and all certifications to the 2013 edition had to expire or be withdrawn by 31 October 2025. Mappings, risk treatment statements and evidence packs should therefore cite the 2022 Annex A control IDs, such as A.8.3 and A.5.15, and not the 2013 numbers such as A.9.4.1. Check older design documents and vendor questionnaires for outdated references before they reach an auditor.

What the 2022 edition and the certification cycle mean for the assistant

The 2022 edition of ISO/IEC 27001 matters for the assistant because its Annex A now lists 93 controls in four themes, taken from ISO/IEC 27002:2022. The access-related controls the assistant depends on sit in the organizational theme (A.5.15 Access control, A.5.18 Access rights) and the technological theme (A.8.2 Privileged access rights, A.8.3 Information access restriction). IAF MD 26:2023 set the end of the transition for older certifications at 31 October 2025, so an organization still describing its controls against the 2013 numbering should update its statement of applicability and its mapping before the assistant is scoped. Confirm with your certification body which edition its current audit plan references.

Certification is a cycle, not a single event. Under ISO/IEC 17021-1, a management system certification cycle lasts three years, with at least one audit, either surveillance or recertification, in every calendar year. For the assistant, this means the permission model, its test records and its change history must stay current across years, not only at the first audit. ISO does not certify organizations, so the assistant's documentation should describe what the organization operates and records, and leave the conclusion about conformity to an accredited certification body. Since 1 January 2026, Global ACI has taken over the roles previously held by the IAF and ILAC, but ISO still points to the IAF CertSearch database for checking accredited certificates. Ask any partner or vendor to show the accredited certificate of the body involved, and check it in CertSearch yourself. ISO's certification page is the natural starting point for that check.

How DeployOpen scopes, builds and evidences permission-aware retrieval

The sequence turns a request for a RAG assistant that respects document permissions into an agreed scope, a tested retrieval filter and an evidence pack the ISMS owner can review. Each step ends with an output the client can inspect.

Agree scope and sources in writing
DeployOpen and the client agree in writing which document repositories, file types, business units and users are in scope, and which collections are excluded, such as restricted material. The client's ISMS owner and data owners confirm the topic-specific access control policy that the assistant must follow. The output is a signed scope document listing each source, its owner and its access rule, which becomes the baseline for every later step.
Map source permissions and identity groups
DeployOpen inventories how each source system grants access, such as folder permissions, site or library roles, shared drive groups or document-level sharing, and maps those rules to identity groups in the client's directory. Inherited and broken permissions are documented, because they are the most common source of over-exposure. The output is a permission map that shows, for each collection, which groups may read which documents and where the mapping is incomplete.
Design and configure the retrieval filter
DeployOpen configures the self-hosted stack so that each query is checked against the requesting user's group memberships before any chunk reaches the model. Options such as per-collection knowledge bases, group-based access rules in the assistant platform or metadata filters in the vector database are compared against the permission map, and the chosen design is recorded. The output is a configuration baseline and a short design note that states where the filter is enforced and where it is not.
Test with negative and positive cases
DeployOpen builds test cases in which users are asked questions whose answers sit only in documents they cannot access, including paraphrased questions, citation probes and attempts to reach restricted content through summaries or document titles. Positive cases confirm that authorized users still receive grounded answers with citations. Each failure is logged, fixed and retested. The output is a test report with pass and fail results per user group, retained as evidence.
Verify permission changes and re-indexing
DeployOpen checks that revoking a user's access or changing a folder permission in the source system is reflected in answers after the next synchronization, and that documents deleted at source are removed from the index. The test confirms the refresh path, not only the initial load. The output is a sync verification record that states the refresh behavior the client should expect and where it is documented.
Prepare the evidence pack for the ISMS owner
DeployOpen compiles the evidence the ISMS owner needs to show how access control applies to the assistant: the signed scope, the permission map, configuration baselines, test reports, sync verification, administrator access records and the logging configuration. Mapping to A.8.3 and A.5.15 is written in plain language so that the owner can align it with the organization's own control documentation. DeployOpen prepares controls and evidence only. It does not issue audit reports or certifications, and the client's independent auditor or certification body decides what is sufficient. The output is a versioned evidence pack handed over with a review meeting.
Offer retainer support for re-indexing and upgrades
After handover, the client can retain DeployOpen for ongoing work such as re-running the negative test suite after upgrades, reviewing new sources before they are connected, and re-indexing when permission models change. Platform releases move quickly, so the test suite is rerun whenever the assistant platform or vector database is upgraded. The output is a maintenance schedule and an updated evidence pack for each change that touches access control.

Permission-aware RAG for ISO 27001 access control