Access decisions shape what can happen to your customers’ information. An employee might need to answer support questions without downloading an entire database. A contractor might need temporary production access that ends when a project closes. A retired laptop might still hold information after its owner has stopped using it.
SOC 2 CC6 brings these situations into a connected discussion of logical and physical access. Its eight criteria help organize decisions about identities, permissions, places, devices, and information movement. This overview introduces that group and explains how to read it. Planned individual criterion articles will explore implementation in more detail.
An access decision has a beginning, a business purpose, and an end. Problems arise when those stages become disconnected. A new employee receives the permissions of a predecessor whose responsibilities were broader. A supplier’s account survives a cancelled contract. A founder’s emergency administrator access gradually becomes the normal way to work.
A useful CC6 program makes these decisions visible. Someone can explain who approved access, why the permissions are appropriate, what would trigger a change, and how the change is completed. That explanation should remain possible when the person who originally created the account is unavailable.
The group also encourages teams to follow information beyond a login screen. Exported files, returned equipment, external connections, and installed software can each create another route to the same customer data. Reviewing them together helps expose gaps between otherwise reasonable safeguards.
The following labels are editorial summaries, not official AICPA criterion titles. Consult the AICPA Trust Services Criteria for the authoritative wording.
A customer reviewing a SOC 2 report wants to understand how access risks are handled in the service they use. Useful questions connect the stated control to an actual decision and its result. Depending on the system and the examination, supporting evidence might help answer questions such as these:
A Type 1 report addresses the system description and suitability of control design as of a specified date. A Type 2 report also addresses operating effectiveness over a specified period and includes tests and results. Read the opinion and any exceptions alongside those dates.
Check which service, systems, and locations are covered. A cloud provider may operate relevant physical controls, with its controls excluded from the service organization’s examination under a carve-out approach. Also identify any controls the report expects customers to perform. These boundaries affect how much the report answers your access questions.
Consider a five-person company with two founders and three employees. One founder could maintain a short system-and-access register while the other reviews sensitive permissions and changes to founder access. Named accounts, a documented approval trail, and a departure checklist may make responsibilities manageable. The team should consider how someone else could remove access if the usual administrator became unavailable.
At a 100-person company, hiring, internal moves, and contractor changes become harder to track informally. The company might connect its personnel records to account provisioning, define standard access by job function, and give application owners responsibility for checking exceptions. A practical review would include applications outside the central sign-in service, where forgotten accounts can remain.
At a 1,000-person company, multiple business units, acquisitions, and shared platforms may create conflicting ownership. A centralized identity team might coordinate with local system owners, while specialist teams manage privileged accounts, facilities, and device disposal. Clear handoffs become important when one team approves a change and another implements it.
These are illustrative arrangements. Headcount alone does not determine the right controls. A small company operating a highly sensitive service may need stronger restrictions and closer oversight than a larger company with a simpler environment. Start with the information at risk, the access paths, customer commitments, and the consequences of misuse. Then choose controls the company can operate and demonstrate consistently.
The individual articles will examine these topics in greater detail, with practical controls and supporting evidence. Links will be added as the articles are published.
Discuss your SOC 2 objectives with Genius GRC and identify controls and supporting evidence that fit your systems, access responsibilities, and sensitive information.
