What SOC 2 CC6.2 asks for when someone joins, moves or leaves
CC6.2 requires that you register and authorize new internal and external users whose access you administer before you issue credentials or grant access, and that you remove those credentials once access is no longer authorized. In plain terms, every account should trace back to an approved request, and every account should stop working when that approval ends. If a customer or auditor asks how accounts get created and removed, this is the criterion they are testing. It sits between CC6.1, which covers the logical access architecture, and CC6.3, which covers role-based access, least privilege and changes to access over time. CC6.2 is the point where a person first gets an identity and the point where that identity is shut off.
The risk behind CC6.2 is orphaned or unauthorized accounts: a contractor whose account outlives the contract, a former employee who still signs in to a billing tool, or a service user created in one application with no request on file. The criterion's 2022 points of focus describe three things an auditor will look for: creating access credentials to protected information assets, reviewing whether those credentials are still appropriate, and preventing the use of credentials that are no longer valid. Two conditions make this hard in practice. First, many organizations have no single system of record for who is authorized, so the HR roster, the identity provider and each application's user list disagree. Second, administrators often create accounts directly inside an application, leaving no request trail that ties the account to an approver.
Before you buy or build anything, confirm three things with your own environment: which systems you administer access to, which of them is the authoritative source for joiners and leavers, and whether each one can be reached from that source without a manual step. Ask your auditor which population of users and applications they will sample, because your joiner and leaver records must cover that population completely. A self-hosted identity stack such as authentik, FreeIPA or Keycloak can centralize this work, with SCIM provisioning to push changes into downstream applications. Whatever you choose, keep the approval, the provisioning event and the removal as linked records, since that trail is the evidence an assessor will request.
Which users, systems and third parties fall under CC6.2
CC6.2 applies to every population whose access the organization administers, and the scope decisions below determine how much registration and removal work the auditor will sample. Settle each one in writing before the examination period starts, because the system description must match what the controls actually cover.
Internal staff and contractors
Employees and contractors who receive accounts to production systems, source repositories, ticketing tools and corporate applications are the core population. Contractors are easy to miss when they are onboarded by a manager outside HR. Check that every account for both groups traces to an approved request, and that the leaver process covers contract end dates as well as resignations. Confirm which contractor accounts the organization administers itself and which are issued by the contractor's employer.
Customer user accounts
Whether customer-facing logins fall in scope depends on who registers and authorizes them. If the organization creates customer administrators, approves access requests or provisions users into a tenant, CC6.2 applies to those steps. If customers self-register with no organization involvement, the control design and the system description need to say so. Ask the auditor early how the boundary is drawn, because customer account handling is one of the most common points of disagreement.
Shared identity provider across applications
When one directory or single sign-on service issues credentials for several applications, registration and removal can be tested once at the identity layer and then per application where local accounts still exist. Map each application to its authoritative source. An application with local accounts that bypass the identity provider needs its own registration and removal evidence, and it should appear in the system description rather than being left out.
Service and machine accounts
Service accounts, API keys, CI runners and integration credentials are not people, but they still grant access to protected information assets. Decide who approves their creation, who owns them and how they are removed when the integration is retired. Many organizations find undocumented service accounts during scoping. Include an inventory with an owner per account, and confirm that credential rotation or revocation happens when an owner leaves.
Third-party and partner users
Auditors and partners often hold accounts in production tools, support consoles or shared portals. Where the organization administers those accounts, CC6.2 applies, and the approval and removal steps must be evidenced. Where a vendor such as a managed service provider controls registration for its own staff, the organization should confirm that the vendor's SOC report covers that process and that the organization's own controls cover the accounts it approves.
Subservice organizations running the identity layer
If a cloud provider or a hosted identity service runs the directory infrastructure, the organization may still administer who gets an account in its own tenant. CC6.2 applies to that administration. Confirm which party performs each step, whether the subservice organization's report covers the relevant controls, and how the organization evidences its own approvals. Describe the carve-out clearly in the system description so the auditor does not have to infer it.
How an assessor tests CC6.2 in a Type 2 examination
This table shows how an assessor approaches each part of CC6.2 in a Type 2 examination, what evidence they ask for and where findings usually appear. A Type 1 report checks whether the design existed at a point in time, while a Type 2 report tests whether the process ran consistently across the observation period, so read each row with the observation window in mind.
| Test area | Evidence requested | Common findings |
|---|---|---|
| Registration and authorization | Access requests, approval records from the named owner, and the written criteria for who may be granted access | Accounts issued before approval was recorded, or approvals given by someone without authority over the system |
| Credential issuance | Provisioning tickets or identity provider logs showing when credentials were created and what access they received | Shared or generic accounts created without a named owner, or access granted beyond what the approved request covered |
| Removal on leaving | Termination or role-change tickets, deprovisioning logs and the timestamp when access was actually removed | Leavers whose access remained active after their end date, or removals completed only for some systems |
| Review of credential appropriateness | Periodic access review records, reviewer sign-offs and evidence of the revocations that followed | No evidence that the review took place, reviews that did not cover all in-scope applications, or open items never closed |
How to implement CC6.2 from approval to removal
This sequence turns CC6.2 from a policy statement into a repeatable joiner, mover and leaver process, where every account traces back to an approval, every change is logged, and every removal is recorded. Each step names the record an assessor will ask to see.
Define the authorization rule for each user type
Start by listing the user types your organization administers, such as employees, contractors, customer support staff, administrators and external partners. For each type, write who may approve access, what the approver must confirm (business need, identity, sponsor) and which systems the type may reach. The owner is usually the control owner for access, with the business sponsor signing off. The output is an approved access standard that names each user type and its approver. An assessor will ask to see this standard and check that it matches how accounts are actually granted.
Name one system of record for identities
Choose a single authoritative source for user identities, such as an identity provider or directory, and decide which systems receive accounts from it. Document which accounts exist outside that source, such as break-glass or service accounts, and why. Platform or identity engineering typically owns this decision, and the security lead approves it. The output is a written inventory of the identity source and its connected applications. Assessors use this inventory to confirm that no credential is issued from a place the organization does not track.
Route every new account through documented approval
Before any account is created, the requester submits a request that names the user, the user type, the systems and the role. An approver defined in the standard reviews it and records a decision with a date. Approval should happen in a tool that keeps the request history, such as a ticketing system or an access workflow in your identity platform. The output is an approval record linked to each account. Assessors sample new accounts and ask for this record, so an account with no approval is an exception to explain.
Provision accounts from the record, not by hand
Create accounts and group memberships by pushing them from the system of record to target applications, so the approved request is the only path to a credential. Where an application cannot be provisioned automatically, the manual step should be made from the approved request and logged. For self-hosted platforms, SCIM provisioning from an identity provider, or directory-based groups, can carry creations and changes. The output is a provisioning log showing who created or changed the account, when, and from which approved request. Confirm the log is retained and searchable, because it is the evidence that approval preceded access.
Automate or time-bound removal when access ends
When a person leaves or no longer needs a system, remove their credentials from the system of record first, then from connected applications. Automated deprovisioning through SCIM or directory group removal is preferred because it does not depend on a person remembering a step. Where removal is manual, the leaver request should close only after the account is disabled and confirmed. Time-bound access for contractors and temporary grants should expire on a set date recorded in the approval. The output is a removal ticket or deprovisioning log for each leaver. Assessors compare leaver lists from HR or contract records against these removals.
Schedule the review of credentials
Set a recurring review in which each account owner or reviewer confirms that every active credential is still authorized and that the approval behind it remains valid. Reviewers should be independent of the people who granted the access where practical. Reviews can run through an access certification campaign in an identity governance tool, which records keep, change or revoke decisions with a deadline. Decide the review frequency in your own standard and state it in your control description. The output is a signed review record with the revocations it produced, which proves the process catches access that should no longer exist.
Which evidence passes a CC6.2 test
An auditor testing CC6.2 selects samples from populations of new users, removals and reviews, then asks for proof that each step happened before access was granted or after it should have ended. The cards below cover the records that carry that proof and how to keep them current between audits.
Access request and approval record
This record shows who asked for access, what they asked for, who approved it and when, and it must exist before the account is created. For CC6.2, the auditor checks that the approver had authority over the system and that the request matches the access actually granted. Check that requests are kept in a ticketing or identity workflow with timestamps, not in chat messages that can be edited or lost. Confirm that each sampled joiner has a request dated before the provisioning date.
Provisioning record with creation date
The provisioning record shows when the account was created in the directory or application and which identity source triggered it. Directory and SCIM-based provisioning logs give a system-generated timestamp that is harder to backdate than a manual entry. In authentik, the SCIM provider pushes user and group creations to target applications, so its event history can serve as this evidence. Confirm that the creation date falls after approval and that the log can be exported for the audit period.
Removal record with effective date
Leaver evidence shows that credentials were disabled or deleted once access was no longer authorized, with the effective date recorded. Auditors compare the termination date from HR or the access request with the date the account became unusable, and they look for gaps. Accounts that are disabled in one system but still active in a connected application are a common exception. Pull removal logs from every application in scope, not only the identity provider, and confirm that deprovisioning events reached each target.
Group and role membership history
Membership history shows which groups or roles a user held over time, so the auditor can confirm that access in a sampled period matched an approved request. Current membership alone cannot show that a user was removed from a group after a role change. Keep snapshots or change events for group membership, and retain them under the access control policy. Directory platforms such as FreeIPA hold users and groups centrally, which makes it easier to export membership changes for the whole audit period.
Periodic access review with reviewer decisions
A periodic review record shows that a designated reviewer checked active accounts and decided to keep, change or revoke each item within a set timeframe. The auditor looks for the reviewer's name, the date, the population reviewed and the action taken on each exception. Access certification campaigns in midPoint produce this trail automatically, which supports the segregation of duties intent behind the review. Confirm that revocations from the review were actually carried out and dated.
Complete and accurate population reports
Every sample an auditor selects comes from a population report, such as a list of all users created or removed during the period. The auditor must be able to confirm the report is complete and accurate, so the report should be generated by the system, show its query or filters, and be reconciled to a second source such as the HR roster. Record who generated each report, when, and with which parameters. Without this, a clean sample can still hide accounts that never appeared in the population.
Which self-hosted open-source tools can produce CC6.2 evidence
authentik's SCIM provider is the part of the tool most relevant to CC6.2. It pushes user and group creations, changes and deletions from authentik to target applications over SCIM 2.0, so that a registration or removal made in one place can flow to the applications that depend on it. authentik is released under the MIT license. Its documentation describes a full sync that runs every hour, and it describes deprovisioning users from the target application when they lose access to it. Those records can support the claim that credentials are removed once access is no longer authorized, provided the logs and sync history are retained.
- Creation and change events: New users and groups created in authentik are pushed to connected applications, and attribute changes follow the same path.
- Deletion and deprovisioning: Users who lose access to an application are removed from that target, which is the leaver side of CC6.2.
- Hourly full sync: A scheduled full sync can correct drift where a single event was missed, so confirm how long a gap can persist in your version.
- Scope limit: Only applications that support SCIM 2.0 receive pushed changes. Other applications need a manual or separate process, and that process needs its own evidence.
- Retained records: Keep the event and sync logs as evidence that a removal occurred and when.
Confirm in your own version how deprovisioning behaves for each target application, how the hourly sync is configured, and what the logs contain before you rely on them as evidence.
FreeIPA uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups, hosts and other network objects. It provides centralized access control and delegated administration through its web UI and command line tools, which lets the organization show who holds the authority to create accounts and who approved them. FreeIPA is licensed under GPL-3.0-or-later. It is most useful as the identity source of record for Linux, internal services and systems that speak LDAP or Kerberos, where a single directory gives one place to create and disable an account.
- Central account store: Users and groups live in one directory, so registration and removal are recorded against a single source.
- Delegated administration: Administrative rights can be granted to specific staff, and the grants themselves become reviewable evidence of who may register users.
- Multi-master replication: Changes replicate between directory servers, which matters for availability of the identity source.
- Host and service objects: The same directory tracks hosts, which helps tie access to machines as well as people.
- Disable versus delete: Confirm whether your procedure disables or deletes accounts on leaving, and keep the change history.
Confirm in your own version which administrative roles can create and disable accounts, how changes are logged, and which applications actually authenticate against the directory.
midPoint supports access certification campaigns, in which designated reviewers decide within a set timeframe whether to keep, change or revoke access items such as role assignments. This addresses a common CC6.2 weakness: access granted at joining or during a move is never taken away, so credentials outlive the authorization behind them. The campaign produces dated decisions by named reviewers, which is the kind of record an assessor samples. midPoint is licensed under EUPL-1.2+.
- Designated reviewers: Each campaign names who decides, which makes the reviewer's authority part of the evidence.
- Timed decisions: Reviewers decide within a set timeframe, so overdue items can be shown and escalated.
- Keep, change or revoke: Each reviewed item ends in a recorded decision, and revocations can be traced to a specific campaign.
- Segregation of duties: Certification also helps counter access accumulation, which connects CC6.2 to the mover controls in CC6.3.
- Scope of evidence: midPoint shows the review, but it does not by itself prove that a leaver's credentials were removed from every application.
Confirm in your own version how campaigns are scheduled, how reviewer decisions are recorded and exported, and whether revocations are applied to the target systems automatically or by a separate step.
Keycloak provides single sign-on, so users authenticate with Keycloak rather than separately with each application. It supports OpenID Connect, OAuth 2.0 and SAML 2.0, and it can broker logins to existing OpenID Connect or SAML 2.0 identity providers. For CC6.2, the value lies in having one place where an application's access is granted and withdrawn, and in the ability to federate with an identity provider the organization already runs. Keycloak is licensed under Apache-2.0.
- Single sign-on: Applications rely on Keycloak for authentication, so disabling a user in Keycloak cuts off access to every application that uses it.
- Protocol support: OpenID Connect, OAuth 2.0 and SAML 2.0 let it front a wide range of applications.
- Identity brokering: Logins can be delegated to an existing OpenID Connect or SAML 2.0 identity provider, which keeps the primary joiner process in that system.
- Session and account control: Disabling an account in Keycloak ends new sign-ins, but existing sessions and tokens need checking.
- Application-side accounts: Local accounts created inside applications that bypass Keycloak remain outside its control and need their own removal evidence.
Confirm in your own version how disabled accounts affect active sessions and tokens, which applications still hold local accounts, and what audit events Keycloak records for account creation and removal.
What meeting CC6.2 costs in money and effort
This table breaks down the money and effort behind registering, authorizing and removing users under CC6.2, showing who is paid, whether each cost is one-time or recurring, and what moves it. Use it to frame a quote request, and note that no price or duration is stated because the figures depend on your user population, systems and chosen auditor.
| Cost component | One-time or recurring | What drives it up or down | How to keep it down |
|---|---|---|---|
| Tooling and licenses | Mostly recurring for hosting and support | The supplied open-source projects (authentik, FreeIPA, midPoint, Keycloak) carry no license fee, but hosting, support contracts and staff time still cost money | Confirm each project's license terms with its maintainers, then budget for hosting, backup and any paid support you choose |
| Engineering time to integrate the system of record and provisioning | One-time, with ongoing maintenance | Number of target applications, whether SCIM 2.0 is supported by each one, and how many HR or directory sources feed identities | Start with the HR system or directory that already holds the joiner and leaver data, and limit the first wave to the applications that hold protected information |
| Process design and approval workflow | One-time to design, then periodic revision | Number of request types, approval chains, and how many teams must sign off on external users and contractors | Use a small set of documented request paths with named approvers and written standards for what each path requires |
| Evidence upkeep and periodic review | Recurring across the observation period | How many joiner and leaver tickets are created, whether records are generated automatically, and how many access reviews are run | Generate provisioning and deprovisioning logs by default and keep tickets linked to the account they create |
| External testing or review | Recurring, at a frequency you set | Scope of the boundary, how many applications are in scope, and whether testing covers account lifecycle or only login | Ask the tester to include account creation and removal in the test plan so one engagement covers several criteria |
| Auditor sampling and fieldwork | Recurring with each examination | Population size of users and terminations, the observation period for a Type 2 report, and how well records are organized | Ask your CPA firm to confirm the sample sizes and population in writing before fieldwork, and keep a complete leaver list ready |
Who does what for CC6.2: your team, a partner and the auditor
Your organization owns CC6.2. That means you decide who may receive access to protected systems, who approves each request, which system of record holds the authoritative list of users, and how quickly access is removed when someone leaves or changes role. These decisions are operating controls, so the auditor will ask who made them, when, and on what basis. A partner can build the workflow, but it cannot be the approver of record for your users.
- Approval rule: Define who may approve access to each application and data store, and what evidence they need before approving an external user such as a contractor or customer administrator.
- System of record: Name the directory or HR-linked source that defines a valid user. Every account in a downstream application should trace back to it.
- Review decisions: Assign reviewers for periodic access reviews, set the review cadence, and sign off on the results, including revocations that reviewers decide to make.
- Leaver timing: Set the deadline for removing access after termination or transfer, and record who confirms that removal happened.
- Exception handling: Decide who may approve a temporary exception, how long it lasts, and how it is closed.
Before engaging anyone, confirm that these owners, rules and timings are written down and that the people named in them accept the responsibility. Auditors test the process as you run it, not as a partner describes it.
An implementation partner such as DeployOpen prepares and integrates the identity systems that carry out your CC6.2 decisions. In a self-hosted environment inside your own cloud account or data center, that work usually covers the directory, single sign-on, provisioning connectors and the documentation that explains how each step runs. The partner prepares systems and evidence for the examination. It does not issue the SOC 2 report, and it cannot stand in for the CPA firm's testing.
- Integration: Connect the identity provider, single sign-on and target applications so that accounts are created and removed from one source.
- Provisioning build: Configure automated creation, change and deletion of users and groups, for example through SCIM-based connectors, and test that removal reaches each target.
- Process documentation: Write the procedures, diagrams and runbooks that describe the joiner and leaver flow exactly as the system performs it.
- Evidence assembly: Set up logs, reports and review exports so that the population of users, approvals and removals can be pulled for the auditor.
- Change control: Route configuration changes to the identity platform through your change management process so they are themselves reviewable.
Ask any partner for a written scope that names each system it touches, who approves the scope, and which deliverables are evidence rather than configuration. Also confirm that the partner has no role in approving access for your users.
The independent CPA firm is the service auditor. It tests whether CC6.2 is suitably designed and, for a Type 2 report, whether the control operated effectively over the period. It samples new and departed users, examines approvals and removal timing, and reads the evidence you provide. The auditor does not design your controls. An implementation partner cannot issue the report, and neither can your own staff. Only the CPA firm issues the opinion.
- Design testing: Confirms that the approval rule, system of record and removal process would address the criterion if they worked as described.
- Operating testing: Selects a sample of joiners, movers and leavers across the period and checks each against the approval and removal evidence.
- Population completeness: Asks how the list of users was generated and whether it includes every system in scope, including external accounts.
- Exceptions: Records any sampled item where approval was missing, late or absent, and reports it in the opinion.
- Report issuance: Issues the SOC 2 report, which only the firm may do.
When selecting a firm, ask for its engagement letter, confirm how it handles any readiness help it offers so that its independence is preserved, and ask what it expects to sample for CC6.2 in your environment.
Where CC6.2 controls usually fall short
Most CC6.2 findings come from the gap between how access is supposed to be granted and removed and how it actually happens in day-to-day operations. The cards below cover the failure points an assessor tests most often, the step that closes each one, and the record that proves it.
Accounts created by hand
Administrators create accounts directly in applications, so no request, approval or owner is recorded. The fix is to route every new internal user through the identity provider, where a joiner request and an approver are captured before credentials exist. Check that each account in a sample traces back to a ticket or workflow record showing who authorized it and when.
Contractors and service accounts missing
Contractors, shared mailboxes and service accounts often sit outside the HR-driven directory, so nobody registers or reviews them. Add them to the same register with a named sponsor, an end date for contractors and an owner for each service account. Ask for the register extract and confirm that every active non-employee identity has a sponsor and an expiry.
Leavers still present in applications
Removing a person from the central directory does not remove local accounts that were created inside individual applications. The fix is automated deprovisioning through SCIM or a similar connector, so changes to users and groups reach each target. Test by disabling a sample test user and confirming the account is gone from every connected application within the expected sync window.
No evidence of periodic reviews
Teams may check access informally, but nothing is recorded that shows who reviewed what, what they decided and what was changed. Schedule access certification campaigns with named reviewers, a deadline for each decision, and a record of revocations. Keep the completed campaign reports, reviewer sign-offs and tickets for every removal as the evidence the auditor will sample.
Customer and partner users outside the process
Customer or partner accounts created by support teams or self-service sign-up can bypass the registration steps used for staff. Bring them under the same authorization rules, with the customer's approved administrator named as the registrar and a documented removal path when a contract ends. Ask for a sample of external accounts and confirm each has an authorizing request on file.
Questions buyers ask about CC6.2 cost, time and effort
How much effort does CC6.2 take compared with other SOC 2 criteria?
CC6.2 is usually one of the more labor-intensive access criteria because it touches every person and every application that holds protected information, not just the core platform. The effort is driven by the number of applications that need user accounts, how many of them are managed through a central identity source, and whether joiner and leaver requests already leave a written trail. A team with one identity provider feeding most systems through automated provisioning will spend far less effort than a team that creates accounts by hand in each tool and records approvals in chat. Ask your assessor early which systems they expect to see in scope, because that list sets most of the work.
How long does it take to get ready for a CC6.2 examination?
Readiness time depends mainly on how many systems hold user accounts and whether the organization needs a Type 1 or a Type 2 report. A Type 1 report covers the design of controls as of a date, so the work is mostly documenting the registration and removal process and showing it exists. A Type 2 report adds an opinion on operating effectiveness over a period, so the controls must run consistently across that period before fieldwork starts. Ask your auditor to confirm the observation period, the sample size they plan to use for joiners and leavers, and the systems they will test. No fixed duration applies to every organization, so the timeline should come from the written scope and your own system inventory.
Can our own team prepare for CC6.2 without an outside consultant?
Yes, a team can prepare for CC6.2 alone if it has engineering capacity, a named owner for identity and access, and a clear picture of which systems issue credentials. The owner should maintain the registration and removal procedure, the list of approvers, and the evidence for each joiner and leaver. An implementation partner such as DeployOpen can prepare systems, controls and evidence, but it does not issue reports, and the independent CPA firm performs the examination and issues the opinion. That separation matters because the auditor must remain independent of the team that built the controls. Decide early which parts your staff will own and which you will buy as a fixed-scope engagement.
What does CC6.2 require from HR and line managers?
CC6.2 depends on HR and managers because they usually know when someone joins, changes role or leaves before any system does. HR needs to feed a dated, approved start and end event into the identity process, and managers need to approve the access their staff are granted. Leaver handling is the part most often missed, since contractors and temporary staff may not appear in the HR system at all. Agree a short written handoff with HR and managers, define who approves external users whose access you administer, and keep the records that show each approval and removal date. Without these inputs, the technical controls can be sound and the evidence still incomplete.
What drives the cost of meeting CC6.2?
The cost of CC6.2 has two parts: the work to build or tune the controls, and the examination fee paid to the CPA firm. Build costs rise with the number of applications that need integration, the number of user populations (employees, contractors, customers), and any gaps in existing identity tooling. Recurring costs include reviewing access, maintaining the procedure, and collecting evidence each period. Examination fees depend on the report type, the scope, and the auditor's fieldwork. Ask any provider to split the quote into one-time build work, recurring operating work, and the examination itself, so you can see which parts scale with your environment.
What should we ask for in a written quote for CC6.2 work?
A useful quote states the systems in scope, the deliverables, the responsibilities of your team and the provider's team, and the acceptance criteria for each deliverable. Ask which applications will be connected to the identity source, how user lifecycle events will be captured, and what evidence will be produced for a sample of joiners and leavers. Request a clear statement of what is one-time and what recurs, and whether support or evidence collection is included after go-live. DeployOpen fixed-scope engagements are agreed in writing before work starts, so ask for the scope, deliverables and timeline in the same document. Confirm with your auditor that the evidence format matches their expectations before you accept the quote.
Which open-source tools can reduce the manual effort of CC6.2?
Several open-source platforms automate parts of CC6.2, which lowers the manual work of creating and removing accounts. authentik's SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0 and runs a full sync every hour, which helps remove access when a person loses their authorization. Keycloak can provide single sign-on so users authenticate once rather than in each application, and FreeIPA stores users and groups in a central directory with delegated administration. Confirm each tool's support for your target applications before you commit, since automated deprovisioning only covers the systems that are connected.
How DeployOpen scopes and prepares CC6.2 evidence
DeployOpen works on CC6.2 by agreeing in writing which user populations, identity sources and applications fall inside the registration and deprovisioning process. We then implement self-hosted open-source identity tooling inside your own infrastructure and document the evidence an independent CPA firm will sample. Your organization keeps ownership of the control and of the decisions about who gets access.
How we scope
- The written scope names the internal and external user populations whose access your organization administers.
- Scope lists every application and system that receives credentials, so none sit outside the joiner and leaver process.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and a quote follows from that scope.
How we build
- We implement a central identity source, such as FreeIPA or Keycloak, as the authoritative record for user registration.
- We configure provisioning connectors, such as the authentik SCIM provider, so account creation and removal flow to target applications.
- We test that a revoked user loses access to each in-scope application, and record the results as evidence for the auditor.
How we hand over
- We document the registration approval steps, the credential issuance process and the deprovisioning procedure for your team.
- We deliver a population list and sample trail showing joiner, mover and leaver events that your CPA firm can request.
- We hand over administrator runbooks and access to the configuration so your staff can operate the controls after delivery.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial fixed-scope work.
- A retainer can cover periodic access certification campaigns, where reviewers keep, change or revoke access items on a set timeframe.
- Only your independent CPA firm examines the controls and issues the SOC 2 report; DeployOpen prepares systems and evidence for that examination.
