CC6.3 Role-based access and least privilege: SOC 2 evidence

What CC6.3 asks for when a SOC 2 auditor reviews role-based access

When a customer or auditor asks how access moves as people change roles, they are asking about CC6.3. The criterion covers the mover side of access control: granting, changing and removing access to data, software and functions based on roles and responsibilities, with least privilege and segregation of duties in mind. It also expects the organization to review those roles and the rules behind them on a regular basis. The joiner and leaver events are handled under CC6.2, so CC6.3 is where the auditor looks at what happens after someone is already inside: a promotion, a transfer to another team, a temporary project role or a change in system design that alters what a role should be able to do.

The risks are easy to describe and hard to contain. Access accumulates when an engineer moves from operations to development and keeps the earlier rights. Orphaned rights remain when a role is retired but its assignments are never removed. Conflicting duties appear when one person can both request and approve a payment, or both write code and deploy it to production. Exceptions pile up because an urgent grant is made in a chat thread and never revisited. Roles drift because the role definitions in the identity provider no longer match what the applications actually allow, and the directory, the cloud accounts and the SaaS tools each hold their own copy of the truth.

Before the audit, confirm three things. First, list every system that holds protected data or privileged functions and identify where its roles are defined. Second, check whether a change of role triggers removal of old access, or whether the old access is only added to. Third, decide who reviews role assignments, how often, and what evidence that review leaves behind. Tools can help here. Self-hosted identity platforms such as authentik can push user and group changes to connected applications over SCIM, and access certification features in platforms such as midPoint let designated reviewers keep, change or revoke role assignments within a set timeframe. Confirm the exact capabilities of any product against its current documentation, including the AICPA 2017 Trust Services Criteria points of focus for CC6.3, before you rely on it for evidence.

Which systems, roles and third parties fall under CC6.3 scope

CC6.3 scope follows the system description, so the systems, roles and third parties listed there set the population of access grants, changes and removals the auditor will sample. The cards below cover the components most often in scope and the decisions that change how much work each one creates.

Production cloud accounts and projects

Production cloud accounts, subscriptions and projects are usually the first in-scope item because they hold the customer data and the infrastructure that runs the service. Role assignments here include administrative, deployment and read-only roles, each mapped to a documented job function. Confirm whether every account in the system description is listed, including accounts used for backups, logging and disaster recovery, since each one needs its own role catalog and review.

Admin consoles and identity providers

Administrative consoles for the identity provider, the directory and the access management tooling control who can grant access to everything else. A user who can change group membership or roles in these tools can extend their own access, so they deserve the tightest role definitions. List each console, who holds administrator rights in it, and how those rights are changed and reviewed.

Databases and data stores

Databases, object stores and data warehouses that hold customer or confidential information are in scope wherever they are reachable by people or service identities. Check both interactive access, such as database console logins and query tools, and programmatic access through application roles. Distinguish schema administration from read access to customer records, because auditors commonly test these as separate grants.

Internal tools that touch customer data

Support dashboards, billing back offices, log viewers and reporting tools often expose customer data without being recognized as production systems. Each one should appear in the scope inventory with its roles, such as agent, supervisor or finance, and the data each role can view or export. Ask whether any internal tool allows bulk export, since that capability usually needs a narrower role than ordinary viewing.

SaaS admin panels and shared tooling

Source control, ticketing, chat, email and other SaaS administration panels can grant access to production secrets, repositories or customer communications. Their administrator roles are frequently held by a small group with broad rights. Record which SaaS applications are in the system description, who holds owner or admin rights in each, and whether single sign-on and provisioning are enforced for them.

Contractors, service accounts and carve-outs

Contractor identities, shared accounts and service accounts are where role-based models most often break down. Contractors need the same role catalog and expiry rules as employees, while service accounts need documented owners and scoped permissions. Scoping decisions matter here: whether a subservice organization, such as a hosting provider, is carved out or included changes which access controls the auditor tests, so confirm that decision against the system description before sampling begins.

How an SOC 2 auditor tests role-based access and least privilege

This table walks through each test step an examiner typically performs for CC6.3, the evidence requested for each step, and the findings that most often appear. Read it as a checklist for preparing the population, sign-offs and reviews the auditor will ask to see before fieldwork begins.

Test area	What the auditor does	Evidence requested	Common findings
Role definitions and permission matrix	Reads the defined roles and maps each role to the permissions it grants across applications, cloud accounts and data stores	Current role catalog, permission matrix, role owner list and approval record for the latest change	Roles defined in a tool but not documented, or permissions granted outside any role
Access grants over the observation period	Samples new grants and checks each against a documented request, a business justification and approval by the right owner before access was active	Access request tickets, approval records, role assignment history and the date access became effective	Grants approved after provisioning, or approvals given by the requester's own manager without a role owner sign-off
Role changes for movers	Samples users who changed teams and checks that old roles were removed and new roles approved in a timely manner	Transfer or HR change records, role assignment before and after the move, and removal timestamps	Users who kept prior access after changing roles, with no removal ticket or review capturing the overlap
Access removals	Samples terminations and role removals and compares the removal date with the date the business instructed removal	Removal tickets, directory deactivation logs and application-level account status records	Late removals of movers or leavers, and removals completed in one system while active elsewhere
Periodic role reviews	Checks that owners reviewed users and roles at the frequency the organization set, and that reviewers decided keep, change or revoke	Review campaign records, reviewer assignments, completed decisions and evidence of follow-up on revocations	Reviews that cover standard users but not privileged or administrative roles, or reviews signed without evidence of decisions
Privileged and sensitive roles	Confirms that administrator, production and data export roles are identified, approved separately and reviewed more closely	List of privileged roles, named holders, break-glass procedures and privileged access approvals	Shared administrator accounts, standing privileged access with no review, or privileged roles missing from the review population
Segregation of duties conflicts	Tests whether any user holds combinations of roles that the organization has defined as conflicting, such as requesting and approving the same change	Conflict rules, conflict reports, exception approvals and compensating controls for any accepted conflict	Conflict rules that exist on paper but are not checked by the system, or exceptions with no compensating control
Population completeness	Checks that the population used for sampling is complete, for example by comparing directory exports with application account listings	System-generated user and role listings with the parameters and date used to produce them	Populations pulled manually from a single system, so accounts in other applications are never sampled

How to implement role-based access in seven steps

This sequence turns job functions into controlled roles, ties every grant and removal to an approved request, and produces the review records an auditor samples to test CC6.3. Each step closes with an output you can show as evidence.

Define roles from job functions
Start by listing the functions people perform, such as application administration, support, finance approval or production deployment, and grouping them into a small set of named roles. Involve the system owners and the managers who approve access, because they know what each function needs. The step is done when every role has a name, a purpose, an owner and a short list of the responsibilities it covers. Keep the role catalog in a versioned document so later changes are traceable.
Map permissions to each role
For each role, record the specific permissions it grants in each system that holds protected data or runs protected functions, including cloud accounts, production databases, source repositories and the internal admin consoles. Remove any permission that no listed responsibility requires, which applies least privilege at design time. The output is a role-to-permission matrix that the owner of each system has reviewed and signed off. Note which permissions are privileged so they receive stricter approval later.
Set the approval path for grants and changes
Document who may request a role, who must approve it, and who may approve privileged roles. Write the path so the approver is never the requester and so that a person who administers a system cannot approve their own elevated access. The output is a written access request procedure with the approver for each role tier, plus a rule for emergency access and how it is closed out afterward. Confirm the approval path matches your segregation of duties decisions in step six.
Enforce roles through the identity provider
Bind each role to groups in your identity provider and assign users to roles through those groups rather than by editing individual accounts in each application. Where the identity provider can provision accounts to downstream applications, configure it so that group membership drives creation, change and removal. For example, an open-source identity platform such as authentik can use its SCIM provider to push user and group changes to target applications over SCIM 2.0 and run a full sync every hour, deprovisioning users who lose access. Confirm the sync behavior and supported attributes for each target application in your own environment before you rely on it. The step is done when a test user's group change produces the expected access change in each target, with the test recorded.
Tie role changes to HR and ticket events
Connect joiner, mover and leaver events to role assignments so that a change in job title or department triggers a review of roles, not only a new account. Use the HR system as the trigger where it exists, and require a ticket for any role change that the HR feed cannot drive. The output is a documented mapping from each HR event to the role action it causes, and a sample ticket that shows the request, approval and completion linked together. Ask your auditor which change sources they will sample so you can prove each one.
Schedule and record role reviews
Set a recurring review in which designated reviewers confirm, change or revoke each role assignment, and record the decision for every item. Access certification tools such as midPoint, an open-source identity governance platform, support campaigns where reviewers decide within a set timeframe whether to keep, change or revoke role assignments, which helps counter access accumulation. Set the review frequency in your own policy, since no fixed interval is given here, and confirm with your auditor which frequency they expect. The output is a completed review record with the reviewer, date, decisions and revocations, retained as evidence.
Document conflicting duties
List the combinations of roles that should not sit with one person, such as creating a payment and approving it, or writing production code and deploying it without review. Enforce those rules in the approval path so a conflicting request is rejected or routed to a second approver, and check existing assignments against the list during each review. The output is a segregation of duties matrix, the exceptions register with an approver and an expiry for each exception, and a record of the check. Keep the matrix current whenever a role or system changes.

Automating mover access with midPoint, authentik and FreeIPA

midPoint is an identity governance and administration platform licensed under EUPL-1.2+. For CC6.3, its most useful feature is access certification campaigns. A campaign assigns designated reviewers who decide within a set timeframe whether each access item stays, changes or is revoked. Those items include role assignments, which is where access tends to accumulate as people move between teams. Reviewing them on a schedule gives you the periodic review of roles that the criterion's points of focus describe, and a dated record of each decision.

Campaign scope: Define which roles, resources and populations each campaign covers, such as privileged roles or finance applications.
Named reviewers: Assign reviewers who manage the people involved, and record who approved each decision.
Decision outcomes: Capture keep, change and revoke decisions, and make sure revocations are actually applied, not only recorded.
Timeframes: Set a review window and escalation path for reviewers who do not respond.
Segregation of duties: Use reviews to find users who hold conflicting roles.

Confirm with your own environment whether midPoint's connectors, roles and certification features match your applications, and whether your team can operate it under the EUPL-1.2+ terms your legal function accepts.

Which evidence passes a CC6.3 test and how to keep it current

An auditor testing CC6.3 looks for a chain of records: the roles that exist, who was granted them and why, when they changed, and whether someone independent checked them. Each card below names one artifact in that chain and what to verify before the examination starts.

Role catalog and permission matrix

The role catalog lists each role, the systems and data it touches, and the responsibilities it supports. The permission matrix maps each role to the specific actions it allows, such as production deployment, database reads or customer record exports. Auditors use these two documents as the baseline for every later access decision, so check that each role has an owner, a last-reviewed date and a version history. A role that exists in the identity provider but not in the catalog is a finding waiting to happen.

Approval tickets for grants and changes

Each grant or change to a role should trace to a ticket that names the requester, the business reason, the approver and the exact access requested. Auditors sample these tickets and compare them with the access that actually appears in the system. Check that approvers hold authority over the system involved and that no one approves their own request. Tickets raised after access was given are a common exception, so confirm your team's rule for emergency access and records it when used.

Mover tickets with timestamps

When an employee changes team or job function, the old access should be removed as the new access is granted. A mover ticket records both steps with timestamps, which shows that accumulated access did not carry over. Auditors often test movers separately from joiners because the removal step is easy to skip. Confirm that your identity records keep effective dates so you can show when each role was added and when it was withdrawn.

Access review campaign records

Periodic access reviews show that someone with knowledge of the role checked who holds it. A complete campaign record includes the population reviewed, the reviewer for each item, the decision to keep, change or revoke, the deadline and the evidence of any revocation that followed. midPoint's access certification feature is one open-source option that assigns reviewers and records decisions within a set timeframe. Confirm that reviews cover privileged roles and cross-system access, not only the default user population.

Segregation of duties matrix

A segregation of duties matrix lists combinations of roles that should not sit with one person, such as requesting a payment and approving it, or writing code and deploying it to production. Auditors check whether the matrix exists, whether it is enforced at assignment, and whether exceptions are approved and time-limited. Maintain the matrix as a controlled document and update it when a new system or role is added, because conflicts often appear through new integrations rather than through hiring.

Identity provider sync logs

Sync logs from the identity provider show that role changes reached the target applications. For example, authentik's SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, runs a full sync every hour and deprovisions users when they lose access. Keep these logs for the whole observation period, and check that failed syncs generate alerts and are investigated. A log that shows a role was removed in the directory but still exists in the application is evidence of a gap that you must explain.

What meeting CC6.3 costs in money and effort

This table breaks down the cost and effort components of CC6.3 by who is paid, whether the cost is one-time or recurring, and what drives it up or down. Use it to structure a quote request and to see where internal time goes before any outside help is hired.

Cost component	Who carries it	One-time or recurring	What drives it up or down
Identity platform licenses	Organization, or none for the open-source tools named	Recurring if a commercial product is chosen; zero license fee for the named open-source tools	Confirm the hosting, support and upgrade costs of self-hosting, since the software itself carries no license fee
Role model design	Internal engineering and security staff, possibly an implementation partner	One-time, then revisited when systems or teams change	Number of distinct job functions and the count of systems that need role mapping; fewer, well-defined roles cost less to maintain
Provisioning and deprovisioning setup	Platform or identity engineers, possibly an implementation partner	One-time integration, with recurring upkeep as applications change	Number of target applications with SCIM or other connectors; manual provisioning for unconnected systems adds ongoing effort
Access review campaigns	Reviewers such as managers and application owners	Recurring on the review schedule set by the organization	Number of access items per reviewer and review frequency; role sprawl makes each review longer
Evidence collection and retention	Compliance lead, security engineers and system owners	Recurring, usually tied to each review and each joiner or mover event	Whether exports are automated and stored centrally; manual screenshots multiply effort
Auditor sampling and testing	External CPA firm, with time spent by organization staff to answer requests	Recurring with each examination period, especially for Type 2 observation windows	Number of role changes and reviews in the period, and how well records match the stated procedure
Remediation of exceptions	Internal teams, sometimes with an implementation partner	Occasional, but can be significant if a review is missed	Clear review deadlines and documented revocation steps reduce the number of exceptions

Where self-hosted open source fits and where it does not

Self-hosted open-source identity and provisioning tools can produce much of the evidence CC6.3 asks for, running inside your own cloud accounts or data center without a per-seat license for those components. A directory such as FreeIPA, which stores users and groups with centralized access control and delegated administration, can hold the group and role structure. An provisioning connector such as the authentik SCIM provider can push user and group creations, changes and deletions to target applications and deprovision users when they lose application access. An access certification tool such as midPoint can run campaigns in which designated reviewers keep, change or revoke role assignments within a set timeframe. Together these give you change logs, provisioning records and review results to show an assessor.

What these tools do not do is decide anything. The organization still owns the role catalog, the rule that maps a job to a role, the approval for each elevated or segregated-duty role, and the decision to keep or revoke an access item during review. A tool that automates a bad role design will automate the bad design faithfully, and an auditor will test whether the approvals on record match the policy. Name a accountable owner for each role and write down who may approve it before you configure anything.

Before you rely on any of these capabilities, confirm them against your own environment. Check whether the SCIM connector supports each target application you need, how often its full sync runs in your deployment, and whether deprovisioning reaches every system where a role grants access, including systems outside the connector's reach. Confirm that the certification campaigns can be scheduled, that reviewers see the context they need, and that revocations flow back to the source of truth. Budget for integration and configuration work, which is usually the largest effort, and ask any implementation partner to show the evidence each configured tool produces before the assessment period begins.

Who owns role design, reviews and the auditor's independent test

CC6.3 splits work across three parties. The organization decides which roles exist, who may hold them and whether access stays appropriate. An implementation partner builds the identity systems, provisioning connections and evidence exports that make those decisions visible. The independent CPA firm tests the design and operation and issues the report, and it cannot be the party that designs the roles it tests.

Role design and approval rules

The organization owns the role catalog: which roles exist, what each one grants, and who approves a request for it. Management should document the rationale for every privileged or cross-functional role and tie it to a job function. Ask whether a named business owner signs off each role before it is used. A partner can model roles in the identity platform, but the decision on what a role may do stays with the organization, and the CPA will ask to see that decision recorded.

Segregation of duties conflicts

Management decides which combinations of access are incompatible, such as creating and approving the same production change or managing users and reviewing their logs. Those conflict rules belong to the organization's risk assessment and control design. A partner can encode the rules as checks in the access tooling, but the auditor will test whether management, not the implementer, set the rules and acted on conflicts that the tooling flagged.

Access review decisions

Periodic reviews only count as CC6.3 evidence when a accountable reviewer decides to keep, change or revoke each item. Tools such as midPoint's access certification campaigns can route items to designated reviewers within a set timeframe, but the reviewer's decisions are management's. Confirm that reviewers are not reviewing their own access and that revocations are carried out and logged.

Identity platform and provisioning build

An implementation partner can configure the directory, identity provider and provisioning connections so that role changes flow to target applications. For example, the authentik SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0 and deprovisions users who lose access. The organization should confirm which systems are in scope, who administers the configuration and who may change it, because that administrative access is itself controlled by CC6.3.

Evidence exports and sampling support

Partners can build reports that export role assignments, change history, provisioning logs and review records in a form the auditor can sample from. The organization must confirm that these exports are complete, that the report logic is documented and that the data is retained for the observation period. Ask the partner to show how an export would be reproduced if the auditor asked for it again.

Independent testing and the report

Only an independent CPA firm tests CC6.3 and issues the SOC 2 report. Under AT-C section 205, management provides written representations, and the auditor forms its own opinion on the design and, for a Type 2 report, the operating effectiveness of the controls. Auditor independence limits what the CPA can do: it may test roles that someone else designed, but it should not design the roles, approve access or prepare the review decisions it will later evaluate. Confirm this boundary in the engagement letter.

Questions buyers ask about CC6.3 cost, effort and outsourcing

How much effort does CC6.3 take to meet?

The effort depends mostly on how many roles, systems and people your organization has, and on whether roles already exist in writing. CC6.3 asks you to grant, change and remove access based on roles, responsibilities or system design, with least privilege and segregation of duties in mind, and to review those roles on a schedule you can show. The first pass is usually the heavy part: defining a role catalog, mapping each application's permissions to roles, and clearing access that accumulated before any of this existed. After that, the work recurs as joiners, movers and leavers, plus each periodic review. Ask any partner to size the effort from your application count, your identity provider's group structure and the number of reviewers you expect to name.

Is a self-hosted identity stack enough for CC6.3?

An identity stack provides the mechanism, but it does not decide who should have what access, and the auditor will test the decisions as well as the tooling. Open-source components such as FreeIPA, which stores users and groups in a centralized directory with delegated administration, or authentik, whose SCIM provider pushes user and group changes to target applications and deprovisions users who lose access, can enforce role assignments consistently. You still need a written role model, approval rules, and evidence of periodic review, often from an access certification tool such as midPoint, which asks designated reviewers to keep, change or revoke access items. Confirm with your vendor which of these capabilities your chosen versions provide before you rely on them.

How long does it take to set up role reviews?

No supplied figure gives a standard duration, so treat any number you hear as a claim to verify. Setup time is driven by how clean your current access data is, how many systems need a review, and whether a reviewer can identify each access item without guesswork. Organizations with a single identity provider and well-named groups usually set up faster than those with local accounts on dozens of applications. Ask a partner for a timeline in the written scope, with the review cycle, the systems covered in the first campaign and the evidence each campaign will produce listed separately.

What does the work need from our internal team?

The work needs named owners more than large headcount. Someone must own the role model and approve changes to it, system owners must be able to say what each permission does, and managers must be ready to act as reviewers within the timeframe you set. Engineers need to wire joiner, mover and leaver events into the identity system and keep the configuration under version control. Your compliance lead needs to keep the review records that the auditor will sample. If these people are not available, a partner can prepare the configuration and the evidence, but the decisions about who should hold which access stay with your organization.

Can an auditor design the roles for us?

No. An auditor, which is a CPA firm performing the SOC 2 examination, tests whether your controls operate as described, and it cannot design your controls without compromising its independence. Your organization owns the role design, the approval rules and the review decisions. An implementation partner such as DeployOpen can prepare the systems, configure the identity tooling and assemble evidence for the examination, and can document how the roles were built. Ask your auditor which preparation work it can accept and which it must not perform, and put the division of responsibilities into the engagement letter.

What should we ask a partner for in a scoped quote?

A scoped quote should state what is in and out of scope, and it should be specific enough that you can check each deliverable at the end. Ask for the list of systems covered, the role catalog and approval process to be produced, the connectors or provisioning rules to be configured, the review campaigns to be set up with reviewers named, and the evidence package to be delivered. Also ask what is one-time work, such as initial design and migration of existing access, and what recurs, such as review cycles, upgrades and monitoring. Confirm who maintains the system after handover and how changes to scope are priced. DeployOpen does not publish a price list; a quote follows from the written scope.

What drives the cost of CC6.3 up or down?

The main drivers are the number of applications that need role-based access, the state of existing access data, the number of reviewers and review cycles, and how many environments such as production, staging and internal tools must be covered. Costs rise when access is granted directly to individuals instead of through groups, when systems lack an API for provisioning, or when the organization has no agreed role model. Costs fall when a single identity provider is already the source of truth and roles are documented. Ask any provider to show which of these factors it has priced and which it has assumed.

Official sources for CC6.3 and the Trust Services Criteria

Start with the primary text before building any access control design for CC6.3. The AICPA 2017 Trust Services Criteria with revised points of focus (2022) defines the criterion itself and the points of focus that describe how organizations typically meet it. Read CC6.3 alongside the other common criteria it depends on, particularly CC1 and CC5, because role design and access reviews only hold up if the control environment and general controls around them are documented. Points of focus are guidance, not separate requirements, so use them to test your design rather than as a checklist you must fully satisfy.

The NIST crosswalk between the NIST Privacy Framework and the AICPA 2017 Trust Services Criteria is useful when your SOC 2 scope includes the privacy category, because it shows where access controls for personal information connect to privacy criteria. For the description of your system, the AICPA 2018 SOC 2 description criteria (DC 200), with its 2022 implementation guidance, governs how you explain which roles exist, who approves them and how access is reviewed. Confirm the current revision with your auditor before drafting, since the description is evaluated against it.

Before your auditor's first request, check the AICPA's proposed revisions to the attestation standards, which the Journal of Accountancy reported in February 2026. The proposal would apply to engagements beginning on or after June 15, 2029, so it does not change a current examination, but ask your CPA firm whether any wording affecting the management assertion or evidence expectations is likely to matter for your renewal cycle. Keep the AICPA's illustrative management representation letter for Type 2 engagements on hand, because it sets out the statements management must make about access controls operating over the period.

CC6.3 Role-based access and least privilege