Safeguard 6.8 role-based access control: evidence

What Safeguard 6.8 role-based access control asks for

If your enterprise is IG3 and you are preparing for an assessment or building access controls from scratch, Safeguard 6.8 asks for two things: a documented set of access rights for each role your people perform, and a review of access to enterprise assets at least once a year to confirm every privilege is still authorized. The Safeguard sits in the Users asset class and the Govern security function, and it applies only at Implementation Group 3, so IG1 and IG2 enterprises do not carry it as a required Safeguard. Start by deciding whether you have a role model at all. Many enterprises have job titles and directory groups but no written statement of what each role is entitled to do, which means there is nothing to review against.

Access drifts for predictable reasons. People change teams and keep the grants from their previous role. Temporary projects leave permissions behind. Contractors and service accounts outlive the work that justified them, and orphaned accounts remain active after their owners leave. Role-based access control limits this drift only if the roles are kept current and someone checks assignments against them. The annual review is the point where you find accumulated grants that no role justifies, and where you confirm that each remaining privilege has a named owner who approved it.

Three things usually make this Safeguard hard. The first is the missing role model, which takes cross-functional work with HR, business owners and system owners to agree what each role needs. The second is unclear ownership of the review: decide who signs off each role, who reviews each system, and what happens to access the reviewer does not recognize. The third is the absence of an account inventory, because an assessor measures coverage against accounts you can list. Confirm with your assessor which inventory and review evidence they expect, and treat the account inventory from Safeguard 5.1 as the starting point for any measurement.

Which accounts, roles and systems fall inside Safeguard 6.8

Safeguard 6.8 looks like one policy, but the scope decisions made before any role is written determine most of the work. The cards below cover the systems, identities and ownership questions to settle first, and they connect back to the account inventory that Safeguard 5.1 provides as a prerequisite for measuring this Safeguard.

Start from the account inventory

The CIS Controls Assessment Specification lists Safeguard 5.1, the account inventory, as a prerequisite for measuring Safeguard 6.8, because the coverage measure depends on knowing which accounts exist. Before scoping roles, confirm that the inventory lists accounts across every directory, application and enterprise asset in scope. An incomplete inventory will show low role coverage for reasons that have nothing to do with the role design, so this check should come first.

Identity sources and enterprise assets

Decide which directories, single sign-on services and enterprise assets issue the access that roles must govern. Roles defined in a central directory are easier to review than roles spread across local accounts on each server or device. Record every system where a user can hold rights, including cloud consoles and software-as-a-service tenants, because each one that sits outside the central source adds a separate role catalog and a separate review.

Employees, contractors and provider staff

Decide which user populations need roles. Employees usually follow a joiner, mover and leaver path, while contractors and service provider staff often hold accounts that are created by hand and never expire. Assign each population a role model, a sponsor and an end date, and check whether provider staff accounts are reviewed under the same schedule as internal accounts. Populations left out of scope tend to accumulate the access that reviews later find.

Service accounts and non-human identities

Service accounts, automation identities and integration keys hold rights that people rarely see. Decide whether they receive roles like human accounts or are documented as an exception with a named owner. Including them raises the number of accounts to classify and review, but leaving them out means the coverage measure can pass while the most powerful identities stay unassigned. Confirm the owner for each non-human identity before the first review.

Enterprise-wide or per-application roles

Choose whether roles are defined once for the enterprise, for each application, or in a layered model with enterprise roles that applications map to locally. Enterprise-wide roles reduce the number of definitions but can grant broad rights that individual applications do not need. Per-application roles match the actual rights more closely but multiply the documentation and the review scope. Most of the effort difference comes from how many distinct role catalogs must be written and kept current.

Role owners and reviewers

Separate the team that defines and approves each role from the team that performs the periodic access review. The role owner documents the rights a role needs for its duties, while the reviewer confirms that each assigned privilege is still authorized. When the same person does both, the review can confirm the design rather than test it. Name both owners in the documented process, because the at-least-annual review requirement fails when no one is accountable for running it.

How an assessor tests Safeguard 6.8 role-based access control

This table walks through the test steps an assessor follows under the CIS Controls Assessment Specification for Safeguard 6.8, with the evidence requested at each step and the findings that typically fail the test. Read it as a checklist of what to have ready before an assessment begins, since the Specification scores the Safeguard as failing when no process exists or the process has not been reviewed within 12 months.

Assessor step	What the assessor does	Evidence requested	Common finding
Confirm the RBAC process exists	Looks for a documented role-based access control process that defines the access rights each role needs for its duties	Written RBAC process, role definitions and the access rights attached to each role	No documented process, so the Safeguard fails
Check the last review date	Reads the revision history and approval record to find when the process was last reviewed	Document version history, approval record and the date of the most recent review	Process last reviewed more than 12 months ago, so the Safeguard fails
Confirm the account inventory	Checks that the account inventory from Safeguard 5.1 exists and is current, since the measurement depends on it	Account inventory export with account identifiers, status and owner	No current inventory, so the coverage measure cannot be calculated
Sample inventoried accounts	Selects accounts from the inventory and checks whether each is assigned a role or group	Role or group membership for each sampled account, taken from the directory or identity system	Accounts with no role or group, or roles that do not match the documented rights
Compare assignments to documented rights	Checks that the access granted through each role matches the rights the process documents for it	Role-to-permission mapping from the directory or application, alongside the RBAC document	Access granted outside any role, or roles holding rights the process does not list
Inspect access review records	Reviews the records of the at least annual access review of enterprise assets to confirm privileges were checked and authorized	Review dates, reviewer names, decisions to keep, change or remove access, and follow-up tickets	Review not performed in the period, or reviews that approve access without recorded decisions
Verify removed access was actioned	Checks that privileges the review marked for removal were removed from the systems	Change records or directory logs showing the removals after the review	Review decisions recorded but no evidence the access was removed

How to implement role-based access control in order

This sequence turns Safeguard 6.8 into a working, repeatable process: an inventory of accounts, a defined set of roles, mapped assignments, an annual review with a clear decision rule, recorded revocations, and a process document that stays current. Each step ends with an artifact an assessor can inspect.

Confirm the account inventory from Safeguard 5.1
Start from the account inventory that Safeguard 5.1 calls for, because the CIS Controls Assessment Specification lists it as a prerequisite for measuring Safeguard 6.8. Confirm that it covers user accounts across the directories, applications and enterprise assets in scope, and that each account has an owner and a status. Your sign-off is complete when the inventory can be exported and reconciled against the directory. Ask your platform team to confirm which systems feed it and which still hold local accounts.
Define roles and the access rights each role needs
Document a role catalog that lists each role, the duties it supports, and the specific access rights it requires to perform those duties. Involve system owners and business managers, since they know what each function needs. Keep rights tied to job functions rather than to individuals. The output is a signed role catalog with a named owner for each role. Confirm that no role grants more than its documented duties require, and record any exceptions with an approver.
Map accounts to roles or groups in the directory
Assign each inventoried account to one or more roles, and implement those assignments as groups in your central directory, such as FreeIPA or your identity provider, so access follows the group membership. Where an application supports automated provisioning, a SCIM connector can push group changes to the target system. Where it does not, record the manual steps. The output is a mapping report showing each account, its role or group, and any unassigned accounts. Coverage of inventoried accounts assigned to a role is the metric the assessment specification uses, so track it from this point.
Set the annual review with named reviewers and a decision rule
Schedule an access review of all enterprise assets at least once a year, and name the reviewer for each system and role. Write a decision rule that states what a reviewer must confirm: the privilege is still needed, the role matches the duties, and the account is active and owned. Define what happens to items that are not confirmed, including who approves a change and how quickly it must be actioned. Access certification tools such as midPoint can run these campaigns and record each keep, change or revoke decision. The output is a review calendar and a signed rule.
Record decisions and revoke or change access
Run the review and capture each reviewer decision with a timestamp, the reviewer's identity and the reason. Apply every change made in the review, removing role assignments that are no longer authorized and moving accounts to the correct role. Where audit trails must be kept, disable accounts rather than deleting them, consistent with Safeguard 6.2. The output is a completed review record that shows every privilege was confirmed or changed. Ask your assessor which form of record they accept before the first cycle.
Keep the process document current
Maintain the written role-based access control process so it reflects the current role catalog, reviewers, decision rule and tooling. Update it whenever a system is added, a role changes or a review reveals a gap, and record the version and approver each time. The assessment specification fails the Safeguard when the process was last reviewed more than 12 months ago, so set a recurring review of the document itself. The output is a dated, versioned process document that matches what the review records show.

Evidence that shows Safeguard 6.8 role-based access control is working

Safeguard 6.8 is satisfied by a set of records that connect a documented role model to the accounts actually assigned to it and to the reviews that confirm those privileges are still justified. Each artifact below answers a different question an assessor will ask, so keep them linked by role name, account identifier and review date rather than as separate files.

Written RBAC process with approval

The documented process defines how roles are designed, who approves them, how a role is changed and how often the model is reviewed. Assessors check that it names an owner, carries an approval record and shows a last review date within the past 12 months, because the assessment specification fails the Safeguard when the process was last reviewed more than 12 months ago. Keep the approval history in version control or a document register, and set a recurring reminder so the review date never lapses between audits.

Role catalog with granted rights

The role catalog lists each role, its business purpose, the systems and entitlements it grants and the people who own it. Assessors compare it against the access actually configured in each system to find roles that grant more than their documented duties require. Export the catalog from the directory or identity platform on a schedule, and record every change with a ticket reference so the catalog shows its own history.

Account-to-role mapping export

This export lists every inventoried account and the role or group assigned to it, which is the data the assessment specification uses for its coverage measure: the share of inventoried accounts assigned a role or group. Accounts with no role are the first finding an assessor raises, so review that gap before fieldwork. Generate the export from the same source as the account inventory required by Safeguard 5.1, and keep dated copies so coverage trends are visible.

Completed access review records

Access reviews at least annually confirm that every privilege is authorized. The record should show each reviewer, the access items reviewed, the decision to keep, change or revoke each one, and the completion date. Campaign tools such as midPoint can record these decisions with set timeframes, but the same evidence can come from signed spreadsheets if they name the reviewer and date. Confirm that reviewers are not reviewing their own access, since assessors look for that conflict first.

Change tickets showing revocation

A review only proves control if it leads to action. Change tickets should show that access flagged during review was removed or altered, with the reviewer decision linked, the executing administrator recorded and the completion date confirmed in the target system. Assessors often sample a few flagged items and trace them forward, so make sure each ticket matches a decision in the review record. Automated deprovisioning through a SCIM provider can create these entries, but confirm what log it writes before relying on it.

Review calendar and schedule

The calendar sets the dates for role reviews, account exports and process reviews, with an owner for each. It shows that the annual cycle is planned rather than reactive, and it gives the assessor a clear view of whether the last cycle closed on time. Record any missed date with a reason and a remediation date, since an unexplained gap is more difficult to defend than a documented delay. Keep the calendar in the same system as the other compliance schedules so it is updated alongside them.

What meeting Safeguard 6.8 costs in money and effort

This table lists the cost components of running role-based access control under Safeguard 6.8, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to build a quote request, and note that the CIS Controls Assessment Specification defines how the Safeguard is measured, not what it costs.

Cost component	One-time or recurring	What drives it up	What keeps it down
Directory and identity tooling licenses	Recurring, if commercial	Number of user populations, applications and directories in scope	Self-hosted open-source directory and governance tools can remove license spend, though hosting and support remain
Engineering time to design roles	One-time, with updates on change	Role sprawl, overlapping job functions, no agreed role owner	Start from a short role catalog tied to job functions and document each role's access rights
Engineering time to map existing accounts	One-time, then ongoing as accounts change	Many local accounts, shared accounts, undocumented group memberships	Use the account inventory from Safeguard 5.1 as the starting data, since the CAS lists it as a prerequisite
Reviewer time for each annual access review	Recurring, at least annually	Large numbers of entitlements, unclear reviewer ownership, manual evidence gathering	Automated certification campaigns with named reviewers and a fixed decision window
Evidence upkeep	Recurring	Manual exports, scattered tickets, role changes not logged	Keep role definitions and review decisions in version-controlled or audited systems
External review or consulting	One-time or periodic, by scope	Unclear scope, no internal design owner, late discovery of gaps	Fixed written scope with agreed deliverables, and internal ownership retained after handover
Auditor sampling	Recurring, per audit cycle	Frequent exceptions, stale reviews older than 12 months, missing approvals	Clean review records showing approvals and the date of the last review

Open-source tools that can produce role and review evidence

Three open-source components can help generate the records Safeguard 6.8 asks for: role assignments, periodic review decisions and the group membership that enforces them. None of them designs the roles or makes the access decisions, and each needs to be confirmed against current project documentation before you rely on it for an assessment.

midPoint access certification campaigns

midPoint, licensed under EUPL-1.2+, can run access certification campaigns in which designated reviewers decide whether to keep, change or revoke role assignments within a set timeframe. The completed campaign records give you dated review evidence for the annual access review that Safeguard 6.8 expects. midPoint does not define what each role should contain or decide whether a reviewer's choice is right, so the role catalog and reviewer assignments remain your responsibility. Check the EUPL-1.2+ terms with counsel before embedding or distributing the software, and confirm the campaign features against the current midPoint access certification documentation.

authentik SCIM provisioning

authentik, licensed under MIT, includes a SCIM provider that pushes user and group creations, changes and deletions to target applications over SCIM 2.0. It runs a full sync every hour and deprovisions users from the target when they lose access to the application. Those sync logs help show that role-based group membership is carried into downstream applications and removed when it should be. authentik does not decide which roles an application should grant, and you must confirm that each target application's group mapping matches your documented role rights. Confirm sync behavior against the current authentik SCIM provider documentation before relying on it.

FreeIPA centralized access control

FreeIPA, licensed under GPL-3.0-or-later, uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups and hosts. It provides centralized access control and delegated administration through its web UI and command line tools. Group objects and delegation rules can record which role each identity holds and who may administer those roles, which supports the access rights documentation Safeguard 6.8 requires. FreeIPA does not write your role definitions or perform reviews, and GPL-3.0-or-later obligations apply if you modify and distribute the code. Verify the directory and delegation features against the FreeIPA project site for your version.

Who owns role-based access control and who can help

Your organization owns role-based access control in full. Safeguard 6.8 asks you to define and maintain the access rights each role needs to perform its duties, and to review access to enterprise assets at least annually to confirm every privilege is still authorized. Those are management decisions, so they stay with named people who can answer for them. Your team also owns the written policy and the record of each review, because an assessor will ask who approved what and when.

Role definitions: Decide which roles exist, what access each role needs, and where a role must be split to keep duties separated.
Approval: Record who signed off each role and each change to it, including the business owner of every application.
Annual review decisions: Decide whether to keep, change or remove each access item during the review, and document the reason for each decision.
Policy and procedure: Maintain the written process that describes how roles are created, changed, reviewed and retired.
Exceptions: Own any privilege granted outside a role, with an owner, a reason and an expiry date.

Confirm that a named owner exists for every role and that the review calendar is written down before any outside party starts work.

Where organizations fall short on Safeguard 6.8 and how to close each gap

Safeguard 6.8 fails in predictable places: the role catalog, the mapping of accounts to roles, the review cycle, and the link between review decisions and what actually changes. The cards below pair each gap with a fix you can check against the CIS Controls Assessment Specification before an assessor does.

No written role catalog

Many enterprises have roles in their directory but no document stating what each role is allowed to do. Safeguard 6.8 asks for the access rights each role needs to perform its duties, so a role with no written rights cannot be reviewed for authorization. Write one entry per role listing the systems, permissions and the business duty it supports, then assign an owner who signs off changes. Check that every role in the directory has a matching catalog entry and that no catalog entry is orphaned.

Roles defined but accounts not mapped

A role catalog that does not match actual account assignments leaves most access outside the model. The assessment specification measures coverage as the share of inventoried accounts assigned a role or group, so unmapped accounts directly reduce the score. Start from the account inventory described in Safeguard 5.1, which the specification lists as a prerequisite for measuring 6.8. Report the unmapped accounts each month and assign them to a role or document why they are exceptions.

Reviews not annual or without decisions

The specification fails Safeguard 6.8 when the process was last reviewed more than 12 months ago, so a review that happened once and was never repeated is a finding. A review also needs a recorded outcome for each access item: kept, changed or revoked. Schedule the campaign with a fixed date, keep the completed decision record with the reviewer name and date, and keep the previous cycle's record so an assessor can see the interval between reviews.

Reviewers approving their own access

When the person who owns a role also reviews who holds it, the review does not test authorization. Segregation of duties is the risk: an administrator who approves their own elevated rights can keep access no one else has checked. Assign each role's review to a manager or role owner outside the group that uses it, and block self-approval in the review tool. Ask the tool vendor or your own administrators to confirm that self-approval is prevented, because it is a configuration choice rather than a default in every product.

Service accounts outside the model

Service accounts, integration users and shared administrative logins often sit outside the role model because they do not belong to a person. Yet they hold rights that can be broader than any employee's. Give each service account a documented purpose, an owner, and a role entry, and include them in the account inventory so the coverage measure counts them. Review them on the same annual cycle, and confirm that a named owner still exists for each one.

Revocations not traced to review decisions

A review that marks access for removal means little if the removal is never made or cannot be shown. Link each revoke decision to a ticket or directory change with a timestamp, and check that the change was applied in the target systems, not only in the review tool. The automated deprovisioning in a SCIM provider such as authentik's can carry revocations into connected applications, but confirm the target system state rather than assuming the sync ran.

Questions buyers ask before hiring help for role-based access control

How much effort does role-based access control take to define and maintain?

The effort depends mostly on how many systems hold accounts, how many distinct job functions exist, and how much access is granted by hand today. Defining roles means listing the access each job function needs, mapping that to the applications and enterprise assets involved, and agreeing the list with the people who own those systems. Maintaining it is recurring work: new roles, role changes, and the annual review that Safeguard 6.8 asks for. Ask a prospective partner to break its estimate into discovery, role design, directory configuration, and the first review cycle, so you can see which parts you would repeat each year.

Can our own team implement role-based access control without outside help?

Often yes, if you have directory administrators who already run group-based access, a clear list of systems, and reviewers willing to make decisions on a schedule. The hard part is rarely the configuration. It is agreeing on role definitions across departments and keeping them current after the first pass. Outside help is most useful when the directory is fragmented, the role catalog must be built from scratch, or the team lacks time to run the first full review. Whichever route you choose, the organization keeps ownership of its controls.

What does the work need from our people?

Three groups carry most of the work. Role owners, usually business managers, must confirm which access their function needs. Directory administrators must create the groups, assign roles and keep the source data accurate. Reviewers must decide, within a set period, whether each access item stays, changes or is removed. Your security or compliance lead should own the written process and evidence. Identify named people for each group before scoping starts, because a quote built on unavailable reviewers will run late.

How long does role-based access control take to put in place?

Timing depends on the written scope, including the number of systems, the state of the existing directory, and how many role owners must agree. No duration can be stated here in advance. Ask for a timeline with milestones tied to deliverables: role catalog approved, directory configured, first access review completed, and evidence package assembled. Fixed-scope engagements agree those dates in writing before work starts, so you can check progress against them.

Can we meet Safeguard 6.8 with the directory we already run?

Possibly. Safeguard 6.8 does not prescribe a product. It asks for documented access rights per role and access reviews at least annually. A directory that already groups users and records assignments can support this. The CIS Controls Assessment Specification also lists the account inventory from Safeguard 5.1 as a prerequisite, because the coverage measure is the share of inventoried accounts assigned a role or group. Confirm with your directory administrators whether every account can be linked to a role or group, and whether review records can be kept. Open-source options such as midPoint support access certification campaigns, and FreeIPA provides a centralized directory, but whether either fits your environment must be confirmed in a technical assessment.

Can an implementation partner issue an attestation that we meet Safeguard 6.8?

No. An implementation partner can design the roles, configure systems, and prepare the evidence, but it cannot issue an audit report, attestation or certification. Only an independent auditor, assessor or certification body can do that, and the CIS Controls are not themselves a certification scheme. Your organization owns its controls and its claims. When you select a reviewer for any framework that references these controls, confirm their accreditation and independence before engaging them.

What should we include in a fixed-scope request for a quote?

A request that produces a comparable quote should state the in-scope systems and user populations, the number of roles you expect or already use, the current directory and identity sources, the review frequency and reviewers involved, and the evidence you need to show an assessor. Also list any systems that are out of scope and who will own them. Ask the vendor to specify deliverables, responsibilities split between your team and theirs, assumptions, and what would trigger a change order. A written scope lets you compare quotes on equal terms.

How DeployOpen scopes role-based access control work

DeployOpen plans, implements, documents and hands over the open-source platforms and access records that support Safeguard 6.8 in your own infrastructure. The organization keeps ownership of its roles, access decisions and attestations, and an independent assessor or auditor tests the result.

How we scope

Agree in writing which roles, applications and enterprise assets fall under the role-based access control process.
Confirm the account inventory from Safeguard 5.1 that the access measurements will draw on, and list gaps to close first.
Record who owns role definitions, who performs the annual access review and who approves exceptions.

How we build

Configure the directory or identity platform so each role maps to documented access rights and group membership.
Set up access certification campaigns so designated reviewers can keep, change or revoke role assignments.
Test that role assignments and removals propagate to target applications and that the results match the documented matrix.

How we hand over

Deliver the role catalog, access rights matrix and review procedure as documents your team can maintain.
Provide review records, campaign exports and configuration evidence mapped to the assessor's test questions.
Walk your administrators through running the next annual review without DeployOpen involvement.

How we support

Offer ongoing support, upgrades and continuous testing of the access platform under a retainer if you want it.
Update role definitions and review workflows when job functions, applications or regulatory scope change.
Confirm with your assessor which evidence formats and review cadence they will accept before the first review cycle.