For IT leads and security officers at mid-sized companies that run mostly on SaaS and must show an auditor or a data protection authority who can access what. Physical access to buildings is out of scope.
An access control policy is the documented set of rules that defines which roles may access which applications and data with which rights, who approves that access, and how it is reviewed and removed. GDPR never uses the term, but Articles 5, 24, 25 and 32 require exactly this restriction and the ability to prove it. ISO/IEC 27001:2022 covers it in controls A.5.15, A.5.18, A.8.2 and A.8.3. In Germany the same document is called a Berechtigungskonzept, and it only survives an audit when the documented target state matches the rights actually granted in every app.
Key takeaways
- GDPR contains no article titled "access control policy"; the duty follows from the accountability principle in Article 5(2) and the security measures in Article 32.
- ISO/IEC 27001:2013 certificates, with their old Annex A.9, expired or were withdrawn on 31 October 2025; audits now run against the 2022 controls.
- Article 21(2)(i) of the NIS2 Directive lists access control policies among the minimum cybersecurity risk-management measures for essential and important entities.
- Portugal's data protection authority fined a hospital EUR 400,000 in 2018, partly because 985 active accounts carried the "doctor" profile against 296 doctors.
- An access control matrix in a spreadsheet is a starting point, not a policy: it lacks owners, approval records and proof that real accounts still match it.
Contents
- What is an access control policy?
- Does GDPR require an access control policy?
- What do ISO 27001 and NIS2 require?
- Template: what goes into an access control policy?
- How to write an access control policy in six steps
- Why access control policies drift in a SaaS environment
- How Corma enforces the policy across SaaS apps
- Frequently asked questions
What is an access control policy?
An access control policy is an information security document that grants access by job function rather than person by person, and makes every grant traceable. It answers four questions: who may access, what, with which rights (read, edit, delete, approve or administer), and who approves, reviews and revokes those rights?
Three principles hold every access control policy together:
- Need to know: people see only the data their task requires.
- Least privilege: every permission is kept as narrow as possible, see the principle of least privilege.
- Segregation of duties: critical steps such as "create a supplier" and "approve a payment" never sit with the same person.
Policy, role model, access control matrix: what is what?
The three terms are often mixed up, yet they describe different layers. The role model groups tasks into roles, the basis of role-based access control (RBAC). The access control matrix translates those roles into concrete rights per application. The policy wraps both and adds owners, processes and evidence. In Germany, this umbrella document has its own name: the Berechtigungskonzept.
How the terms differ
| Term | What it defines | Typical format |
|---|---|---|
| Access control policy | Principles, owners, processes and evidence for all access, in the sense of ISO control A.5.15 | Approved policy document |
| Role model | Which roles exist and which tasks they bundle | Role catalogue |
| Access control matrix | Which role gets which permission level in which application | Table of roles by applications |
| Berechtigungskonzept | The German umbrella document combining all three | Policy with appendices |
Does GDPR require an access control policy?
Not by name, but in substance yes. The text of the GDPR never mentions an access control policy. Yet any controller must be able to demonstrate that only authorised people access personal data, and that proof is hard to produce without a documented policy.
Guides disagree here: some call the policy a legal obligation, others say GDPR does not explicitly require it. Both fall short. The obligation follows from several articles read together:
Where GDPR implies an access control policy
| Provision | What it requires | Consequence for the policy |
|---|---|---|
| Art. 5(1)(f) | Protection against unauthorised processing through appropriate technical or organisational measures | Restrict access to what is necessary |
| Art. 5(2) | Accountability: the controller must be able to demonstrate compliance | Document rules, log decisions |
| Art. 24(1) | Implement measures and be able to demonstrate that processing complies | Name owners and processes |
| Art. 25(2) | Data protection by default, explicitly including the accessibility of data | Restrictive default roles, extra rights only on request |
| Art. 29 and Art. 32(4) | People with access to personal data process it only on the controller's instructions | Tie access to tasks and instructions |
| Art. 32(1)(b) and (d) | Ongoing confidentiality, and regular testing of the measures' effectiveness | Schedule access reviews |
Source: consolidated GDPR text on EUR-Lex, including the 2018 corrigendum (OJ L 127, 23.5.2018).
What a missing policy can cost: a hospital in Portugal
How a regulator treats access failures is visible in decision no. 984/2018 of the Portuguese data protection authority CNPD, dated 9 October 2018, against a hospital whose name is redacted in the published version. The system held 985 active users in the "doctor" functional group, while the hospital's 2018 activity plan listed 296 doctors. Only 18 accounts had ever been deactivated, the last in November 2016, and social services staff could open the full clinical file of every patient.
The CNPD imposed EUR 400,000 in total: EUR 150,000 each for breaches of Article 5(1)(c) and (f), and EUR 100,000 for Article 32(1)(b) and (d). Most of the amount therefore fell under the Article 83(5) ceiling (up to EUR 20 million or 4% of worldwide turnover), not the Article 83(4) ceiling (up to EUR 10 million or 2%). Treating access failures as a purely technical Article 32 issue underestimates the exposure.
The frequently quoted case of the Haga hospital in the Netherlands is different: the Dutch authority faulted the lack of two-factor authentication and of regular log reviews in 2019. A Hague court later reduced its EUR 460,000 fine to EUR 350,000, a final ruling.
What do ISO 27001 and NIS2 require?
ISO/IEC 27001:2022 spreads the topic across several Annex A controls, which together require rules and evidence for access control, access rights and privileged rights. The NIS2 Directive adds the same expectation for entities in its scope. The table below lines up both frameworks with the evidence auditors typically request.
Audit matrix: one requirement, two frameworks
| Requirement | ISO/IEC 27001:2022, Annex A | NIS2, Art. 21(2) | Typical evidence |
|---|---|---|---|
| Set rules for access | A.5.15 Access control | (i) access control policies | Approved policy with version and date |
| Manage identities uniquely | A.5.16 Identity management | (i) | List of all accounts mapped to a person |
| Grant, change, review, revoke | A.5.18 Access rights | (i) | Requests, approvals, review logs, revocation records |
| Limit privileged rights | A.8.2 Privileged access rights | (i) and (j) multi-factor authentication | Justified list of admin accounts |
| Restrict access to information | A.8.3 Information access restriction | (i) | Access control matrix per application |
| Segregate duties | A.5.3 Segregation of duties | not explicit | List of incompatible roles |
Control titles as listed in the BSI cross-reference table for ISO/IEC 27001:2022 (6th edition, 2023); NIS2 points from Directive (EU) 2022/2555.
Why older templates citing "A.9" no longer fit
Many free templates still refer to Annex A.9 of ISO/IEC 27001:2013. The transition to the 2022 version ended on 31 October 2025: under IAF MD 26, all certificates based on the 2013 version expired or were withdrawn at that date. A policy that still argues with A.9.2.5 in an audit needs to be remapped to A.5.15, A.5.18, A.8.2 and A.8.3.
NIS2: access control policies are now a legal minimum
Article 21(2) of Directive (EU) 2022/2555 (NIS2) lists the measures that essential and important entities must take "at least", and point (i) reads: "human resources security, access control policies and asset management". Member states transpose this at their own pace. Germany did so on 6 December 2025, when its implementing law came into force and section 30 of the BSI Act began requiring concepts for access control. For the remaining duties, see the NIS2 compliance checklist for IT teams.
If you have German entities: the BSI ORP.4 module
In Germany, the reference text on this topic is module ORP.4 (identity and authorisation management) of the BSI IT-Grundschutz Compendium, 2023 edition. Its basic requirement ORP.4.A3 asks companies to document accounts, groups and rights profiles and to check regularly whether that documentation reflects the rights actually granted. Requirement ORP.4.A16 expects a written access rule for every IT system and every application, which in a SaaS company means every app, not just the three largest.
What auditors actually test
A well-written document often gets through the first certification. The real test comes later, when the auditor samples live accounts.
"Auditors often grant the initial certification despite lacking access management but latest at the second audit, non-conformities in this area can lead to the loss of the certification."
Samuel Bismut, co-founder and CTO of Corma, December 2024
What auditors want to see is spelled out in the Satelia case study. Satelia's technical project manager needed to know which tools people use, how often they use them and when access was granted: "Without having those details, we couldn't move forward with the ISO 27001 and SOC2 certifications." To build the review cycle behind that evidence, follow the ISO 27001 user access review roadmap.
Template: what goes into an access control policy?
An audit-ready access control policy fits into ten chapters. Each chapter answers a question an auditor or a data protection authority may ask, and points to the requirement behind it. Copy the outline into Word, Confluence or Notion.
Outline to copy
| No. | Chapter | Content | Reference |
|---|---|---|---|
| 1 | Scope and objectives | Entities, sites, all applications including SaaS, categories of data | GDPR Art. 24, A.5.15 |
| 2 | Ownership | Policy owner, owner per application, approvers, reviewers | A.5.15 |
| 3 | Principles | Need to know, least privilege, segregation of duties, restrictive defaults | GDPR Art. 25(2), A.5.3 |
| 4 | Role catalogue | Business roles with task descriptions and role owners | A.5.15 |
| 5 | Access control matrix | Role by application by permission level | A.8.3 |
| 6 | Request and approval | Who requests, who approves, deadlines, time-limited exceptions | A.5.18 |
| 7 | Joiners, movers, leavers | JML workflow with deadlines for revocation | A.5.18 |
| 8 | Privileged and technical accounts | Admin accounts, service accounts, API tokens, break-glass access | A.8.2 |
| 9 | Third parties | Contractors, freelancers, temporary access with an end date | GDPR Art. 29 and 32(4) |
| 10 | Reviews and evidence | Review cadence, logs, handling of deviations | GDPR Art. 32(1)(d) |
Example: extract of an access control matrix
Chapter 5 is the core. The fictional example below shows a matrix for a company of about 150 people running typical SaaS applications.
Fictional access control matrix
| Role | Google Workspace | CRM | HR software | Accounting | Code repository |
|---|---|---|---|---|---|
| Sales | User | Edit | Own profile | No access | No access |
| HR | User | Read | Edit | No access | No access |
| Accounting | User | Read | Own profile | Post, not approve | No access |
| Finance lead | User | Read | Own profile | Approve, not post | No access |
| Engineering | User | No access | Own profile | No access | Write |
| IT administration | Admin (separate account) | Admin (separate account) | No access to payroll data | No access | Admin (separate account) |
Two details make a matrix audit-ready. First, it splits posting and approving across roles. Second, it adds an "owner" column per application: in Corma, for example, access reviews can be routed to the app owner, the access owner, the contract owner or the manager. Naming those owners up front saves you from explaining in the audit who actually decided.
How to write an access control policy in six steps
Order matters: deriving roles from the rights people hold today simply freezes existing sprawl. Start with the inventory and the tasks, not with the permissions.
1. Inventory every application and account, including unknown ones
The first list is almost always too short. At Satelia, the external IT provider only delivered reports without user permissions or usage frequency; an automated inventory then surfaced 160 applications, far more than the 30 found in manual reports. Each of them has its own permission model, and each belongs in scope.
2. Derive roles from tasks
Roles describe tasks, not people. A good role catalogue is small enough for a manager to understand and precise enough that exceptions stay rare. If you run Active Directory, see this worked example of role-based access control in Active Directory. Automation depends on this step rather than replacing it. As a quality manager in manufacturing put it in a Gartner Peer Insights review in July 2026: "Those situations require careful role mapping before automation can be trusted."
3. Assign rights and rule out conflicts
Only now does the matrix take shape. For each role and application, pick the lowest permission level that still lets people do the job. In parallel, list incompatible combinations, such as maintaining supplier data and approving payments. The guide to separation of duties in IAM shows how to detect such conflicts systematically.
4. Define the request and approval path
Every right outside the default role needs a request and an approval that can be found later. A tiered model works well: managers approve standard rights, and admin rights also need the application owner's sign-off. Emails and ticket comments rarely hold up as evidence, while self-service access requests with approval workflows record each decision.
5. Handle joiners, movers and leavers
The JML process ties the policy to HR events. The blind spot is usually the mover: people who change teams gain new rights but often keep the old ones. Corma co-founder Héloïse Rozès describes how fragmented the picture gets: a single IT identity can have five email addresses, seventeen accesses and several permission levels, with data often held by HR and never reconciled (Journal du Net, December 2025, translated from French). Automated provisioning at onboarding anchors the role from day one instead of adding rights one by one.
6. Schedule access reviews and close deviations
GDPR asks for regular testing without a fixed interval. A risk-based cadence works: quarterly for admin rights and systems holding sensitive data, every six or twelve months for everything else. Corma itself evaluates user access internally every quarter and revokes it upon termination. What matters is that every review ends with an outcome: kept, revoked or justified as an exception. Automated access reviews route those decisions to the right reviewers and log them.
Why access control policies drift in a SaaS environment
Because the document is written once, while rights change every day. In a company running dozens of SaaS apps, the question is not whether reality deviates from the policy, but where. Three deviations show up almost every time:
Typical gaps between policy and reality
| Deviation | Typical cause | How it shows up |
|---|---|---|
| Orphaned accounts | Former employees keep licences, for instance under an email address other than their work address | Reconciling each app's accounts with the HR list |
| Privilege creep | Movers gain new rights and keep the old ones | Comparing actual rights with the role in the matrix |
| Shadow IT | Teams buy apps themselves without any entry in the policy | Discovery through the identity provider, the browser or spend data |
The first deviation is the most dangerous because it stays invisible: a leaver is cleanly offboarded in the identity provider, yet an account in a business app registered with a personal email lives on. The article on orphaned accounts and deprovisioning explains how to find and close them.
The Portuguese hospital decision shows what happens when this reconciliation never takes place. Done by hand across 50 or 150 apps, it rarely happens on time. An identity governance and administration (IGA) platform reads the actual accounts from connected applications and compares them with the target state defined by roles and approvals.
How Corma enforces the policy across SaaS apps
A tool does not write your access control policy. It shows where daily practice deviates from it and closes the gaps with evidence. The same Gartner Peer Insights reviewer noted: "Corma did not solve that automatically, but it made the ownership gaps visible." That split of responsibilities is exactly what Corma supports:
- Inventory: Corma discovers SaaS and AI apps in use, including outside the identity provider, and maps identities to their permissions and owners.
- Requests and approvals: approval steps can go to the manager, the app owner or the contract owner, and can be split by role, for example standard versus admin.
- Leavers: Corma suggests users with an upcoming termination date from the HR tool for offboarding and revokes access app by app, via API where available.
- Access reviews: reviews run per application with assigned reviewers and deadlines, and each revocation decision creates a remediation task.
- Evidence: review decisions and remediation tasks export as CSV, along with a final report for the auditor.
- Orphaned accounts: accounts not matched to an active person, such as former employees with active licences, are flagged separately.
At Mrge, the technical lead singled out offboarding: Corma shows whether a given licence has been revoked or not, which is precisely the evidence a leaver process needs.
For a GDPR-driven policy, it also matters where the tool itself stores access data. Corma is ISO/IEC 27001:2022 certified and hosts data in the European Union. Questions about where data is hosted and maintained come up more and more, COO Nikolai Fomm said in May 2026, and as a European company Corma has a good answer. Corma is listed in the 2025 Gartner Magic Quadrant for SaaS Management Platforms.
Want to see how far your access control policy is from the actual state of your SaaS apps? Request a Corma demo
Frequently asked questions
What is an access control policy in ISO 27001?
In ISO/IEC 27001:2022, the access control policy is the set of rules behind control A.5.15 "Access control". It defines how access to information and applications is granted, changed, reviewed and removed, and it is supported by controls A.5.18, A.8.2 and A.8.3.
What is a Berechtigungskonzept?
Berechtigungskonzept is the German term for a documented access control policy combined with its role model and access control matrix. It has no exact English equivalent and maps closely to ISO/IEC 27001 controls A.5.15 and A.5.18.
What is an access control matrix?
An access control matrix is a table that lists roles in rows and applications in columns, with the permission level for each pairing, such as read, edit or admin. It is the operational core of an access control policy but does not replace the policy itself.
How often should access rights be reviewed?
GDPR requires regular testing of security measures without setting an interval. In practice, admin rights and systems holding sensitive data are reviewed quarterly, other rights every six or twelve months, and the policy document at least once a year.
Is a spreadsheet enough as an access control policy?
A spreadsheet can serve as the access control matrix, not as the policy. It lacks owners, approval processes and, above all, proof that the rights actually granted in each application still match the table.
Who owns the access control policy?
Legally, the company as data controller is responsible and must implement and demonstrate appropriate measures under GDPR Article 24. Operationally, the IT lead or the information security officer usually owns the policy, supported by an owner for each application.
What GDPR fines apply to access control failures?
Breaches of GDPR Articles 25 or 32 can lead to fines of up to EUR 10 million or 2% of worldwide annual turnover. When the core principles of Article 5 are breached as well, the higher ceiling of EUR 20 million or 4% applies.
