Access governance

Access governance, security, and compliance evidence

Access governance is about answering one question with certainty: who has access to what, and why. ServiceChanger automates group and role memberships in Microsoft Entra ID and on-prem Active Directory using a deterministic attribute model. A single attribute value, such as department, job title, or location, maps to a defined set of groups and roles. Every assignment is recorded, so you keep a clear audit trail that links each attribute to the access it granted. This page explains how that model supports your security and compliance work without overpromising what software can deliver.

How attribute-to-group mapping works

ServiceChanger drives memberships from your user attributes across your hybrid directory:

• Attribute as the source of truth:One attribute value, for example department equals Finance, defines which groups and roles a user should hold. You define the mapping once and it applies to everyone who matches.
• Entra ID and on-prem Active Directory:Memberships are kept in sync across both directories using Entra ID dynamic groups, Entra Connect, and a PowerShell runbook on a hybrid worker for on-prem groups.
• Deterministic, not predictive:Access is granted by explicit mappings you control. There is no scoring, no machine learning, and no guesswork. The same input always produces the same memberships.
• Out of scope by design:ServiceChanger is not a privileged access management tool. By default it reacts to the attributes already in your directory and focuses on group and role membership. If you want to connect your HR system for onboarding and offboarding, we build that as custom work using automation accounts and runbooks in Azure.

Who has access to what: the access governance audit trail

The most common audit question is also the hardest to answer by hand: who has access to what, and which decision put them there. ServiceChanger records every membership change against the attribute value that triggered it, so you can reconstruct who had what access at any point in time. When an auditor asks why a user is in a group, you can show the mapping and the attribute that granted it rather than guessing. This who-had-what-when history is the practical core of access governance, and it removes the manual spreadsheet work that usually surrounds an access review.

Compliance frameworks: evidence, not a certificate

ServiceChanger does not make you compliant. It produces evidence that supports the access-control parts of common frameworks:

• GDPR / AVG least privilege:The audit trail shows that access to personal data follows a documented mapping and the principle of least privilege, which supports access-control accountability under the regulation.
• ISO 27001 access control:Membership records help you evidence controls A.5.15 access control and A.5.18 access rights, by showing how rights are granted, reviewed, and removed against attributes.
• NIS2 access obligations:For organisations in scope of NIS2, the who-had-what-when history supports access-control and accountability obligations during an assessment.
• What this is not:ServiceChanger is not an access-certification or recertification suite, and using it is not itself a compliance certification. It gives your auditors and security team verifiable records to work from.

Why attribute-driven memberships strengthen security

Manual group management drifts. People change roles, leave the team, or get one-off access that nobody remembers to revoke, and that drift is where security gaps appear. Because ServiceChanger drives memberships from attributes, a change to a user's department or job title automatically adjusts their groups and roles in Entra ID and on-prem Active Directory. Least privilege becomes the default state rather than a periodic cleanup project. The license module tracks usage so you can see assigned licenses against actual need, though it does not itself govern access. Together this gives a tighter, more consistent access posture that you can prove with the audit trail.

What access governance actually means

The three questions you should always be able to answer:

People use the term access governance for a lot of different things, so it helps to be concrete. Access governance is the practice of being able to answer three questions about every account and every group in your directory, at any moment, with evidence to back the answer.

• Who has access:Which users hold which groups and roles right now, across Entra ID and on-prem Active Directory. Not a rough idea from a spreadsheet, but the actual state of the directory.
• Why they have it:The reason behind each membership. In a well-run setup that reason is a rule, for example department equals Finance, and not a one-off decision that nobody wrote down.
• Is it still correct:Whether the access someone holds today still matches what their role needs. People move teams, change jobs, and leave, and access that made sense a year ago is often the access that causes a problem now.

Governance versus access management

It is worth separating two words that get mixed up. Access management is the day-to-day work of granting and removing access: adding a user to a group, giving someone a role, revoking it when they leave. Access governance sits one level up. It is the set of rules, ownership, and evidence that decides whether that day-to-day work is correct and keeps it correct over time. You can have access management without governance, and most drift comes from exactly that: access gets handed out and removed, but nobody owns the rules or checks the result. Good user access governance turns those daily grants into something you can explain and prove. ServiceChanger works on the management side by driving memberships from attributes, and it feeds the governance side by recording every change so the evidence exists without extra effort.

NIS2 and access control

What NIS2 expects around access, in plain terms:

NIS2 is the EU directive that raises the bar for cybersecurity across a wide set of sectors. It does not hand you a checklist of specific technical settings, but it does require appropriate risk-management measures, and access control is one of the areas an assessor will look at. The point below is practical, not alarmist: if you already run tight, documented access control, most of what NIS2 expects on this topic is already covered.

• Risk-based access measures:Access decisions should follow from a documented approach, not from habit. Being able to show that memberships come from defined rules is exactly the kind of measure that fits.
• Demonstrable least privilege:It is not enough to intend least privilege. You have to be able to show that users hold the access their role needs and no more, and that excess access gets removed.
• Incident traceability:When something goes wrong, you need to reconstruct who could reach what and when. An audit trail of membership changes over time is what makes that reconstruction possible.
• Who it applies to:NIS2 covers essential and important entities in the sectors it names, and it pushes obligations down to their suppliers and service providers. If a larger customer is in scope, expect access-control questions to reach you as their supplier even if you are smaller.

An audit trail is not a compliance product by itself, but it is the raw evidence behind these obligations. It turns "we think access is under control" into records you can show. ServiceChanger produces that record as a by-product of automating memberships, which is the low-effort way to have it ready before anyone asks.

ISO 27001 and access rights

ISO 27001 is the international standard for an information security management system. Its Annex A groups a set of controls, and a specific block covers access. If you are working toward the standard or already certified, these are the access controls an auditor will test, and membership records help you evidence each one.

What an auditor wants to see is not a slide that says you do access control. They want the mapping that defines who gets what, records that show rights were granted and removed against that mapping, and proof that access was reviewed and acted on. ServiceChanger supplies the records; the policy and the review decisions stay with your team. ServiceChanger itself is not ISO 27001 certified, so treat it as a source of evidence for your own certification, not as a certification of its own.

Access reviews that stay workable

What makes a review survive contact with reality:

Periodic access reviews are where good intentions go to die. The theory is clean: once a quarter, an owner looks at every membership and confirms it still belongs. In practice the reviewer gets a list of hundreds of entries with no context, no memory of why each one exists, and a deadline. The result is review fatigue, and review fatigue almost always ends the same way: approve everything and move on. A review that rubber-stamps the current state proves nothing and fixes nothing.

• Smaller scopes:Split the review by group, application, or team instead of dumping the whole directory on one person. A short, focused list gets read; a long one gets approved blindly.
• An owner per group:Every group needs a named owner who understands what it grants and who should be in it. Reviews without an accountable owner have no one to catch the wrong entries.
• Rules that keep rights correct:The biggest win is reducing what the review has to catch. If memberships already follow attributes and adjust when someone changes role, most drift never accumulates. The review becomes a control that confirms the rules held, not a cleanup that fixes months of neglect.

This is the practical role ServiceChanger plays in reviews. It does not run the review campaign for you, and it is not a recertification suite. What it does is keep memberships continuously aligned with attributes and log every change, so by the time a review runs there is far less to correct and a full history to check against. The review turns into a verification step rather than a rescue mission.

Implementing access governance

A workable rollout is incremental. You do not need to fix everything at once, and each step below is useful on its own:

1. Inventory (one to two weeks):Pull the current state of groups, roles, and memberships across Entra ID and on-prem Active Directory. You cannot govern what you have not listed, and the raw inventory usually surfaces the first surprises.
2. Name owners (one week):Assign a responsible owner to each group that grants meaningful access. This is organisational work, not technical, but nothing else holds up without it.
3. Set the baseline (one to two weeks):Decide, per role or department, which memberships are correct. This is your target state expressed as attribute-to-group rules, and it becomes the reference everything is measured against.
4. Clean up drift (one to three weeks):Compare the inventory to the baseline and remove memberships that do not belong. Do this before you automate, so you are not automating a mess.
5. Automate assignment (one to two weeks):Turn the baseline into live rules so memberships follow attributes such as department, job title, or location. From here, correct access becomes the default state instead of a manual task.
6. Set up the review process (one week):Define scopes, owners, and cadence for periodic reviews. Because the rules now keep rights correct, the review is a check rather than a cleanup.
7. Reporting (ongoing):Use the audit trail to answer who has what, why, and since when, on demand. This is the evidence you hand to auditors and the data your security team works from.

Common access governance mistakes

Most access governance problems are not exotic. They are the same handful of mistakes, and each one is avoidable:

• Treating it as a yearly project:Governance is not a once-a-year cleanup. Access drifts every day, so a model that only corrects things at review time is always months behind reality.
• No owners:Groups without a named owner rot. When nobody is accountable for a group, wrong memberships pile up and no review catches them.
• Only asking who, not why:A list of who has access is half the picture. Without the reason behind each membership you cannot tell correct access from leftover access, and every review turns into guesswork.
• Not recording exceptions:There are always exceptions to the rules. If you grant one and do not write it down, it looks like drift at the next review and either gets wrongly removed or wrongly approved.
• Reviews without consequences:A review that flags a problem and then changes nothing is theatre. If findings do not lead to removed access, the review costs time and buys no security.
• Automating before cleaning up:Automating a directory that is already wrong just makes the wrong state permanent. Clean up drift first, then let the rules hold the corrected state.

FAQs on access governance, security, and compliance