Safeguard 6.1 Establish an access granting process

What the access granting process requirement asks for and why assessors check it

Safeguard 6.1 requires a written process for granting users access to enterprise assets when they are hired or move to a new role, and the enterprise has to actually follow it. Ideally the process is automated. An auditor or customer who asks for proof of controlled access is usually looking for two things: a document that defines who approves access and what gets provisioned, and records showing that the document matches what happened. In CIS Controls v8.1, the Safeguard sits in the Documentation asset class and the Govern security function, and it belongs to all three Implementation Groups. That makes it part of IG1, the essential cyber hygiene baseline every enterprise is expected to meet. Assessors therefore treat it as a foundation for the rest of Control 6, because later Safeguards on revoking access and central control assume that someone decided, in advance, what access a person should receive.

The risk of ad hoc grants is simple to describe. When a manager asks a colleague in chat to add a new starter to a shared drive, a production system or a finance application, nobody records who approved it, what was granted, or whether it fits the person's role. Over time the directory holds accounts that no one can justify, and the organization cannot show which rights existed on a given date. The CIS Controls Assessment Specification scores this Safeguard as failing when no access granting process exists. Where a process does exist, its completeness is checked against three events: new hire, rights grant and role change. A document that covers only new hires will not pass, which is a common gap when role changes are handled informally by line managers.

What usually makes this hard is the gap between the procedure on paper and the practice in the business. Managers grant access through email threads, tickets get closed without an approver, and contractors receive credentials outside the normal path. Before an assessment, confirm three things: that the written process names the approver for each type of access, that your ticketing or identity records can show the request, approval and grant for a sample of recent joiners and movers, and that the three events are each covered. A ticketing tool such as GLPI or Zammad can hold the request trail, and an identity platform can enforce the grant, but the organization still owns the decision about what access is appropriate.

Which systems, teams and third parties the access granting process covers

Safeguard 6.1 asks for one granting process that covers every way a person or service gets access to enterprise assets. The cards below are the scoping decisions that determine how much of the process you must write, automate and evidence, and who owns each step.

Enterprise assets and applications

Start with an inventory of every system that holds access to enterprise assets, including directories, SaaS applications, cloud consoles, VPN and internal tools. Each one needs a defined path from request to grant, or the process has gaps an assessor will find. Check whether each application can be provisioned through a central directory or whether someone must create the account by hand. Manual paths are where requests slip, so record them as explicit exceptions with an owner.

HR as the source for joiners and movers

Decide whether your HR system is authoritative for new hires and role changes. When it is, a status change in HR can trigger provisioning and reduce manual requests, which lowers the effort of covering the new hire and role change events the completeness check looks for. When HR is not authoritative, IT or managers must raise every request, and you need a reconciliation step to catch the ones that were never raised. Confirm which system holds the official job title and manager.

Managers who approve requests

Define who approves access to each asset class, such as the line manager for standard applications and a data owner for sensitive data. Record the approver in the ticket so the grant can be traced back to a business need. Approval rules that depend on one person's memory tend to fail during staff turnover. Decide how approvals are delegated during absence and whether approvers must re-confirm access on a schedule.

Contractors and service providers

Contractors and outsourced providers often receive accounts outside the HR process, so they are the most common gap in the granting process. Decide who sponsors each external identity, how long it lasts and who removes it at contract end. The process should cover provider staff who log in to your systems and any accounts used by provider platforms. Confirm that contract terms match the access the provider actually holds.

Shared and privileged accounts

Shared accounts and privileged administrator access need their own grant path, because a single shared login hides who used it. Decide whether such accounts are allowed at all, who approves them and where each use is recorded. Privileged grants usually need a second approver and a named owner. Note that Safeguard 6.5 and 6.8 cover administrative access and role-based rights in more detail, so keep this card focused on who may request and approve.

How an assessor tests the access granting process

This table sets out how an assessor applies the CIS Assessment Specification to Safeguard 6.1, from the pass or fail gate to the sampling and evidence that support the score. Read it as a checklist of what to prepare before an assessment, since the specification defines what is measured but leaves the test method to the assessor.

Test step	What the assessor does	What to have ready
Existence gate	Confirms a documented access granting process exists. If none exists, the Safeguard is scored as failing and no further testing is needed.	A dated, approved written process that names its owner and scope.
Completeness check	Checks whether the process covers three events: new hire, rights grant and role change.	A process section or procedure for each of the three events, with no gaps between them.
Document review	Reads the process against the three events and checks that it names the systems, approvers and tickets involved.	Access request template, approval matrix and the system list the process covers.
Walkthrough	Asks the process owner and an HR or line manager to explain how a new joiner or mover gets access in practice.	A named owner who can walk through the flow end to end, including any automated provisioning.
Sampling of joiners	Selects a sample of recent new hires and traces each one's access grants back to an approved request.	Joiner records with request, approval and grant timestamps for each sampled user.
Sampling of movers	Selects a sample of employees who changed role and checks that their access was changed to match the new role and old rights were reviewed.	Role change records, the approval trail and before and after entitlement lists.
Common findings	Undocumented role changes, grants made by email or verbal request, and access granted outside the defined process.	Reconciliation of directory or application accounts against approved requests to find exceptions early.
Scope of the specification	The CIS Assessment Specification defines what to measure, not how. The assessor chooses sample sizes and methods under its own professional standards.	Ask the assessor or certification body which sampling method and sample size they will apply.

How to build an access granting process that passes testing

This sequence turns Safeguard 6.1 into a written, followed process with named owners, defined joiner and mover events, and retained records that an assessor can sample against the Assessment Specification.

Confirm the in-scope enterprise assets
Start from the asset inventory and list every enterprise asset and application that users need access to, including cloud accounts, SaaS tools, network services and internal platforms. Record each system with its owner and the identity source that controls it. Done means you have a scope list that IT, security and the business owners have each reviewed and signed off, so the process has a defined boundary to test against.
Define the joiner and mover events
Write down the events that trigger access grants: a new hire, a grant of additional rights to an existing user, and a change of role. The Assessment Specification checks that the process covers all three, so each event needs a named trigger, such as an HR record change or a request form. Done means a short event table that maps each trigger to the systems it affects.
Assign approval and fulfillment owners
Name who approves each access request and who carries it out for each system. Separate the approver from the person who provisions access where your team can do so, and record a backup for each role so requests do not stall. Done means an ownership matrix that a reviewer can read without asking anyone which team to contact.
Write the access granting procedure
Draft the procedure in plain steps: how a request is raised, what information it needs, who approves it, how access is granted, how the grant is confirmed to the requester, and where the record is kept. Route the draft through the people who own the process and get formal approval from the accountable manager. Done means an approved, dated procedure document that people can actually follow, which is the artifact an assessor reads first.
Choose manual or automated fulfillment
Decide, per system, whether access is granted by a ticket worked by a person or by an identity provider that pushes accounts and group memberships automatically. Automation with an identity provider can reduce error and produce logs, while a ticket workflow remains acceptable where systems cannot be integrated. Confirm each option with the system vendor and your own environment before committing. Done means a documented decision for each system in scope.
Build the request template and provisioning record
Create a standard request ticket that captures the requester, the user, the system, the role, the approver and the approval date, then add a provisioning record that captures who granted the access and when. Open-source service desk tools such as GLPI or Zammad can hold these tickets and their history. Done means a sample ticket and record that together show a full request from approval to grant.
Run a pilot with real requests
Run the new procedure against actual joiner, mover and access requests for a defined period agreed internally, and check each one against the written steps. Note every deviation, gap and workaround, then update the procedure and retrain the owners. Done means a pilot log showing real requests processed under the procedure and the corrections made from them.
Retain the outputs for assessment
Keep the approved procedure, the event table, the ownership matrix, the scope list, the pilot log and a sample of completed tickets and provisioning records in a controlled location with version history. Ask your independent assessor which sample period and format they will need. Done means an evidence folder that lets someone who was not involved reconstruct how a given user received access.

Evidence that shows a working access granting process

Safeguard 6.1 is tested on whether the process exists and whether people follow it, so the evidence has to show both the written rule and a trail of real grants. The cards below cover the artifacts an assessor is likely to request, and how to keep each one current between assessments instead of rebuilding it when an assessment is scheduled.

Approved written access granting process

The document is the first thing to show. It should name the owner, carry a version number and an approval date, and state who may request access, who approves it, and how the three events are handled: new hire, rights grant and role change. Assign a review date to the owner and store the document under version control so each change has a traceable history. Ask whether the process is documented in a form the CAS completeness check can read, and confirm it covers all three events by name.

Sampled joiner and mover tickets

Assessors pick a sample of recent hires and role changes and trace each one back to a request and an approval. A ticket from a service desk such as GLPI or Zammad can serve as this record if every access change links to a request, a named approver, the access granted and a completion time. Check that tickets exist for every sampled event, that approvals came from the right person before access was granted, and that no grant was made by a verbal request alone.

Provisioning logs and directory change records

The approved ticket proves intent, and the directory log proves the grant happened. Keep change records from the identity provider, such as authentik's SCIM provider logs for pushed user and group creations and changes, and from FreeIPA or its 389 Directory Server audit log. Match timestamps between the ticket and the log entry. Confirm that log retention is long enough to cover the assessment period and that logs cannot be edited by the administrators who create the accounts.

Role definitions used at grant time

When access is granted, the organization should be able to show which role was assigned and what that role contains. Keep a dated export of group and role membership, along with the definition each role had at the time of the grant. Without this, an assessor cannot confirm that a grant matched the approved rights. Review role definitions with the same owner who approves the process, and record each change so a grant from last year can still be explained.

Exception and emergency grant records

Some grants fall outside the normal path, such as urgent access during an incident or a temporary grant for a contractor. Each exception needs a record with the reason, the approver, the expiry date and the evidence that access was removed or converted into a standard grant. Assessors often test exceptions separately because they are where a process tends to fail. Ask for a count of open exceptions and confirm that none has passed its expiry date without review.

Periodic review of the process

The process should be reviewed on a set schedule by the owner, and the review should leave a record: the date, the reviewer, the findings and the changes made. Compare the review against recent sampled tickets to see whether the steps in the document match what staff do. If a gap appears, such as a team granting access outside the ticket path, record it and track the fix. Schedule this review as a recurring task so it happens between assessments, not only in the weeks before one.

What meeting Safeguard 6.1 costs in money and effort

This table lists each cost component of running an access granting process for Safeguard 6.1, who is paid for it, whether it is one-time or recurring, and what drives it up. Use it to structure a quote request: most of the spend sits in internal process design, integration work and ongoing evidence upkeep, not in software licenses. No fixed figures are given because none were supplied for this Safeguard.

Cost component	Who is paid or who spends time	One-time or recurring	What drives the cost
Process design and written procedure	Internal HR, IT and security staff, plus any outside reviewer	One-time, then revised on change	Number of joiner, mover and grant paths, and how many approval steps exist
Software licenses for open-source tooling	No license fee for self-hosted open-source platforms	Not applicable to licensing	Confirm each component's license terms in your own environment before deployment
Hosting and operations of self-hosted tools	Internal platform team or a service partner	Recurring	Number of hosts, availability needs, backup and patching obligations
Integration engineering for automated provisioning	Implementation partner or internal engineers connecting HR, directory and application systems	One-time build, then recurring maintenance	Number of target applications, HR system maturity, and quality of source data
Ticketing workflow for manual grants	Service desk staff who process requests	Recurring	Joiners and movers per month and the share of grants that still need manual steps
Evidence upkeep	Internal control owner who keeps approvals, tickets and sync logs	Recurring	Sampling frequency, retention period, and how much evidence is generated automatically
External review of the process	Independent reviewer or assessor for design and testing	Periodic, often tied to an assessment cycle	Scope of the review, number of business units, and prior findings
Auditor sampling and testing	Independent auditor or certification body, paid by the organization	Recurring with each assessment	Population size of joiners and movers and the quality of retrievable records

Open-source tools that produce access granting evidence

Safeguard 6.1 is satisfied by a process that people follow, and the evidence is the record of each grant. The four tools below cover different parts of that record: automated provisioning, the directory that holds identities, and the request tickets that show who approved what. Each card names what the tool can produce and what to confirm in your own environment before relying on it.

authentik SCIM provider

The authentik SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, and runs a full sync every hour. For Safeguard 6.1, this turns a role change in the identity source into a grant or removal in the target application, with the sync history as a timestamped trail. Confirm that each application you need supports SCIM 2.0 provisioning, and where it does not, decide whether a documented manual step with a ticket will serve as the grant record.

FreeIPA central directory

FreeIPA uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups, hosts and other network objects. It gives one place to create accounts and group memberships, and it supports delegated administration so that the people approving a grant do not all hold full directory rights. Evidence comes from the group membership history and the administrator actions that created each account. Confirm which applications in your estate can authenticate against LDAP or Kerberos before counting FreeIPA as the source of record.

GLPI Assistance tickets

The GLPI Assistance module lets users create, follow and process tickets, problems and changes following ITIL practices, with plannings, statistics, recurrent tickets and a Kanban view. Each access request can be a ticket with a requester, an approver, a fulfiller and timestamps, which is the record an assessor asks to see for the process. The statistics help show that requests are closed on a regular basis. Confirm that your approval rules are configured in the tool and that tickets are the only route for access requests.

Zammad request handling

Zammad is a web-based helpdesk that brings customer communication from email, chat, telephone and social media into one ticket system. It suits organizations where access requests arrive by email or through a service desk mailbox, because the request, the replies and the approval all sit in one ticket. The evidence is the conversation thread on each request. Confirm that the requester identity is verified before fulfilment and that approvals made by email are recorded in the ticket rather than only in an inbox.

Who owns the access granting process and who prepares the evidence

The organization owns Safeguard 6.1. The access granting process is a business and governance decision: someone must decide which roles exist, which systems each role may reach, who approves a request, and what happens when a person changes jobs. An implementation partner can draft these, but only the enterprise can adopt them and make staff follow them. The CIS assessment specification tests whether the process exists and is followed, so the internal team must also run it day to day.

Process ownership: A named owner, usually in HR, IT operations or identity management, maintains the written process and reviews it when the organization changes.
Role definitions: Managers and system owners agree which access each job function receives, so new hires and movers are granted a defined baseline.
Approval authority: The organization records who may approve a request and for which systems, including exceptions.
Operational records: Tickets, approvals and grant dates are kept by the team that performs the grants, not reconstructed later.

Before engaging anyone, confirm internally who signs off the written process and where approvals are recorded today.

Gaps that cause access granting findings and how to close them

Assessors testing Safeguard 6.1 usually find the same handful of gaps: the process lives in people's heads, role changes go untracked, and grants happen outside any record. Each card names one gap, why it fails the test, and the single action that closes it.

Process exists only as tribal knowledge

When the granting steps are known only to a few administrators, the enterprise cannot show a written process it actually follows, and the Safeguard fails at the first check. Write the steps down with the request form, the approver, the fulfillment team and the evidence kept at each stage. Then ask two staff from different teams to walk through a recent grant and confirm the document matches what they did.

Role changes never trigger a review

Transfers accumulate access because the process only covers new hires, and the assessment specification's completeness metric expects role change to be covered alongside new hire and rights grant. Make a job change create a request that reviews existing entitlements and removes those the new role does not need. Sample several transfers from the last year to see whether old access was actually removed.

Grants made through chat or email

Access granted by a message in a chat channel or an email reply leaves no ticket, no approver record and no timestamp that an auditor can sample. Route every grant through the helpdesk so that the request, the approval and the fulfillment are one linked record. Confirm that the helpdesk rejects or flags grants that were never requested through it, and that no administrator grants access directly in the target system.

No named owner for approvals

If nobody is accountable for approving a given system, requests stall or are approved by whoever is available, which makes the approval meaningless. Assign a named approver or data owner for each application or resource group and record that assignment in the process document. Check that the approver for a sampled grant is the person the document names for that system.

HR events not connected to requests

When hiring, transfers and departures are recorded in an HR system that does not trigger access requests, provisioning depends on someone remembering to ask. Connect the HR start date and position change to the request workflow so that a new hire or transfer opens the access request automatically. Confirm with HR which events are recorded, how quickly they reach IT and who receives the notice.

Applications outside the directory

Applications that keep their own user lists sit outside the granting process, so a grant in the directory never reaches them and the process cannot show what they hold. Inventory each application that authenticates users, then connect it to the central directory or provision it through SCIM where the vendor supports that. Where an application cannot be connected, document it as a manual grant with its own approval step.

Questions buyers ask about the access granting process

Does Safeguard 6.1 require the access granting process to be automated?

No. Safeguard 6.1 asks for a written process that the enterprise actually follows, and it describes automation as the preferred form. A documented manual process can meet the Safeguard if people follow it consistently for every hire and role change. Automation becomes more valuable as the number of users, applications and access paths grows, because manual steps are where grants get missed or delayed. Before you decide, confirm with your assessor how they will test the process, since the CIS assessment specification checks whether a process exists and whether it covers new hires, rights grants and role changes, not whether a specific tool is used.

How long does it take to implement an access granting process?

No duration can be given without knowing your environment, so ask for one in writing rather than relying on a general estimate. The main drivers are the number of systems that need access granted, how many of them already integrate with a central directory or single sign-on service, how clearly HR records identify job roles, and whether the current process lives in people's heads or in tickets. Writing the process down is usually the quickest part. Connecting it to identity sources, approval paths and the applications themselves takes longer. Ask any provider to break the timeline into discovery, design, build, testing and handover, and to state which of those steps depend on your HR and application owners.

Can our internal team implement Safeguard 6.1 without outside help?

Often yes, for the documented process alone. Writing the process, defining the three events it must cover (new hire, rights grant and role change), assigning owners and keeping records can be done by a compliance lead with HR and IT input. Outside help is more useful for the technical side: connecting a directory or identity provider to target applications, configuring provisioning, and producing clean evidence from logs and tickets. Your organization always owns its controls. An implementation partner prepares systems and evidence, and only an independent auditor or certification body issues a report or certificate. Be clear with any provider about which of these responsibilities is theirs.

What does the access granting process need from HR and line managers?

The process depends on HR and managers for accurate triggers. HR must reliably record hires, transfers and departures, ideally in a system that can feed the identity source. Managers must approve the access their staff need for a given role and confirm when someone moves. Ask for a RACI table during scoping that names who raises each request, who approves it, who fulfills it and who keeps the record. Also agree on the exact fields HR must capture, such as job title, department and start date, because these often determine which groups and roles are assigned automatically.

How does Safeguard 6.1 relate to the CSF 2.0 Govern mapping and to Safeguard 6.2?

CIS places Safeguard 6.1 in the Govern security function in v8.1, and its Navigator mapping links it to NIST CSF 2.0 GV.RR-04, which concerns human resources practices in the cybersecurity risk management strategy. The mapping means the granting process should be treated as a governed HR practice, with defined ownership and documented steps, not only as an IT task. Safeguard 6.2 covers the reverse direction: revoking access on termination, rights revocation or role change. The two work together. A granting process that is never paired with timely revocation leaves stale access behind, so design both processes from the same role and identity data.

What should we ask a partner to include in a fixed-scope quote?

Ask for a written scope that lists the systems in scope, the three events the process must cover, the identity sources and target applications, and the evidence to be produced. The quote should separate one-time work, such as process design, integration and testing, from recurring work, such as support, upgrades and periodic reviews, which may be offered as a retainer. Ask which deliverables are documentation, which are configured systems, and who signs off on each. Confirm that the partner prepares evidence but does not issue assessment conclusions, and ask what happens if your environment differs from the assumptions in the scope. DeployOpen agrees scope, deliverables and timelines in writing before work starts and issues a quote from that written scope.

Which open-source tools can support an access granting process?

Several open-source platforms can support the technical side, but the choice depends on your environment and must be confirmed in testing. authentik's SCIM provider can push user and group creations, changes and deletions to target applications over SCIM 2.0, run a full sync every hour, and deprovision users when they lose access. FreeIPA stores users and groups in 389 Directory Server with centralized access control and delegated administration. For the request and approval workflow and its records, GLPI's Assistance module supports tickets, change processes and ITIL-style practices, while Zammad provides a shared ticket system. Confirm each tool's fit with your applications and your auditor's evidence expectations before you commit.

How DeployOpen scopes and prepares access granting evidence

DeployOpen works on Safeguard 6.1 as a fixed-scope engagement inside your own infrastructure: we help you define the granting process, wire its steps into the systems that issue access, and prepare the records an assessor will ask for. The organization owns the process and its control decisions, and an independent auditor or assessor issues any report or certification.

How we scope

Agree in writing which enterprise assets, applications and identity systems the granting process must cover.
Confirm the three events the assessment checks: new hire, rights grant and role change.
Identify the HR source, approval owners and ticketing tool that will trigger each access request.

How we build

Configure provisioning in the directory or SSO platform the client already operates, such as authentik or FreeIPA.
Connect request and approval steps to a ticketing workflow, for example GLPI or Zammad, so each grant is recorded.
Test grant, change and denial paths in a non-production environment before the process goes live.

How we hand over

Deliver the written access granting procedure, with roles, approval steps and exception handling for the organization to adopt.
Provide a sample evidence pack showing requests, approvals and provisioning logs for each of the three events.
Document configuration and the evidence locations so the client's staff or an assessor can reproduce the results.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Review the granting process at the intervals the client sets, including after HR system or directory changes.
Ask your auditor or assessor which evidence format they expect before the assessment window opens.