SOC 2 Type 1 access control setup: SSO, MFA, onboarding and offboarding

For a SOC 2 Type 1, access control means one identity provider with SSO and MFA, a written and approved joiner process, a leaver process that removes access fast, and proof that the design exists. The criteria behind it are CC6.1, CC6.2 and CC6.3, and a Type 1 only looks at design at a point in time.

What do the criteria actually say?

We read the AICPA 2017 Trust Services Criteria with the 2022 points of focus. CC6.1 asks for logical access security over protected information assets, including an inventory of those assets. CC6.2 covers registering and authorizing new users before credentials are issued, and removing credentials when access is no longer authorized. CC6.3 covers authorizing, changing and removing access based on role, with "least privilege and segregation of duties" in mind.

The criteria do not name SSO or MFA. They are the common, easy to evidence way to meet the intent. You can choose another design, but you must be able to explain it.

Step 1: build the asset and system list

Write down every system that holds customer data or can change production: cloud console, code host, CI, database, ticketing, email, HR and finance tools. Mark an owner for each. That list drives everything else, and CC6.1 expects it.

Step 2: centralize identity

Pick one identity provider. Connect every system you can with SSO. For those that cannot do SSO, keep a short exceptions list, with a named owner and a reason. Enforce MFA at the identity provider, and on break glass accounts too, with those credentials stored offline.

Step 3: define roles, not individuals

Create a role matrix: engineer, support, finance, admin. For each role list the systems and permission level. Grant by group membership. This is how you show least privilege without arguing about each person.

Step 4: write the joiner process

A request, an approval by the system owner or the manager, a ticket, and access granted by group. Keep the ticket. That ticket is your CC6.2 evidence. Background checks and policy acknowledgments belong in the same checklist if your policies require them.

Step 5: write the leaver process

HR notifies IT, IT suspends the identity provider account, then removes direct accounts, shared secrets and API keys the person owned. Set a target such as same business day, write it down, and then meet it. Check that the person is gone from each system the next day.

Step 6: add a review

Even a Type 1 benefits from one completed access review: export users per system, have the owner confirm each, record removals. It shows the control works, and it is practice for a Type 2.

What evidence should you keep?

• System inventory with owners
• Identity provider settings showing MFA enforced
• Role matrix and approval record
• Three sample joiner tickets and three sample leaver tickets
• Completed access review with sign off
• Exceptions list with reasons

Mistakes to avoid

• Shared admin accounts with no owner.
• Offboarding that covers email but not the code host or cloud console.
• A policy that says same day removal while tickets show a week.
• Service accounts and API keys left out of the review.

What to do

1. List systems and owners.
2. Turn on SSO and enforce MFA at the identity provider.
3. Publish the role matrix.
4. Run joiner and leaver tickets for real events and keep them.
5. Complete one access review.
6. Keep a dated export or screenshot of each setting.

Quick check

How Safeguard helps automate this

Access evidence is the part teams redo by hand every time. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems instead of by screenshot, and monitoring keeps running between audits. That saves the repeated export-and-screenshot cycle and gives your team time for other work.

Safeguard also adds technical evidence from your real code and dependencies, through scans, SBOMs and reachability, which supports the secure development side of your system description. Its agent can open tested fix pull requests for vulnerable dependencies. This is off by default, every category starts on Manual, and you choose which categories run automatically and at what approval level. An independent CPA firm performs the SOC 2 examination. Safeguard helps prepare and keep evidence ready, and does not guarantee a result.

Want to see it on your own stack? Book a call.

Sources

• AICPA, 2017 Trust Services Criteria with revised points of focus (2022)

Last reviewed: 18 October 2026.