When a task falls between teams
A contractor finishes work on Friday. Their manager assumes IT will remove access. IT expects the contract owner to submit a request. The contract owner has closed the purchase order and considers the engagement complete. On Monday, the contractor can still reach a customer support system.
Each person understood part of the process. Nobody had responsibility for getting the entire job finished.
SOC 2 CC1.3 addresses the organizational arrangements behind that problem. In plain language, management establishes the structure, reporting relationships, and decision authority needed to achieve the organization’s objectives, with board oversight. The AICPA Trust Services Criteria provide the authoritative wording. In a SOC 2 program, those arrangements should make the responsibilities supporting the in-scope system clear.
This is the third article in our SOC 2 Guide. The fictional examples show possible implementations for companies with five, 100, and 1,000 people. Choose an approach according to the business’s risks and complexity; headcount does not determine a required control design.
Organizational structure and reporting lines
An organization chart can show who reports to whom. A responsibility map explains how work crosses those reporting lines. Both may be useful when a control involves people from several teams or an outside provider.
Start with the work that protects your service and fulfills your commitments. Identify who owns access management, production changes, incident response, recovery, vendor oversight, and other relevant processes. Then clarify who receives information about unresolved problems and can authorize a response.
The CC1.3 points of focus address organizational structures, reporting relationships, delegated authority, and responsibilities, including those of external parties. They help organizations apply the criterion; they are not a separate mandatory checklist. A particular chart, job title, or responsibility-matrix format is not universally required.
Assign the decisions as well as the work
Return to the contractor’s departure. Follow the workflow from the event that starts it to the evidence that access has ended. Several assignments need to be explicit:
- The engagement owner records the end date and triggers the departure process.
- The appropriate decision-maker resolves unusual access requirements or proposed exceptions.
- An authorized operator removes the relevant access.
- The process owner checks completion across the systems in scope and escalates anything unresolved.
A person can hold more than one role, especially in a small business. Consider whether concentrated authority creates an unacceptable risk and what review or other safeguard would address it. Someone checking a consequential decision needs enough knowledge and authority to challenge it.
A RACI matrix, which distinguishes responsible, accountable, consulted, and informed roles, can help. A concise written assignment can work just as well when it makes the same decisions clear. Keep a current record of who fills each role so a departure or reorganization does not leave a title without an owner.
Define authority and escalation
An owner needs the information, resources, and authority to carry out the assignment. A person responsible for confirming offboarding cannot do that reliably without knowing which applications the contractor used or obtaining removal records from the relevant operators.
Define what the owner may decide, where approval is needed, and who resolves competing priorities. For example, a team lead might approve routine access within an established role, while broader privileges require a system owner’s approval. State who can authorize an exception, its permitted duration, and how it will be revisited.
Give urgent failures a clear escalation route. If a provider cannot remove access before the required deadline, someone should be empowered to assess temporary restrictions and decide the next step. The route should still work when the usual manager is unavailable or involved in the issue.
Name a backup for critical responsibilities and verify that the person can use the approved instructions and systems. Backup coverage should preserve individual accountability and access controls. Informal password sharing creates another problem rather than solving the first one.
Include service providers
Outsourcing changes who performs a task and introduces another handoff. Document the provider’s duties, the company’s retained responsibilities, and the information each needs from the other.
Suppose a managed IT provider disables the central identity account, but a support application has separate local accounts outside the provider’s service. Assign that remaining step explicitly. Establish who requests the work, who handles a failed removal, and what evidence confirms completion.
Check the actual agreement and service configuration. A broad statement that the provider manages IT may not cover every application, credential, or support window. Keep an internal decision owner for consequential risk choices and a route for resolving disagreements about scope.
What this could look like at 5 people
Consider a bootstrapped software company with two founders and three employees. One founder leads product and engineering; the other leads customer relationships and business operations. They share management responsibilities and cannot create a separate department for every control.
They could maintain a short assignment list covering their essential processes. The technical founder owns access removal and production changes. The operations founder maintains contractor end dates, initiates departures, and checks completion. An employee with appropriate training provides technical backup for routine tasks under defined authority.
For a contractor departure, the operations founder opens the request with the end date and known systems. The technical founder removes access and records the result. The operations founder compares the completed work with the application list and follows up on gaps. A system needing specialist attention remains visible until someone resolves it.
Before either founder takes leave, they walk through coverage and escalation. Where neither founder can evaluate a specialized issue, they obtain qualified help. The founders retain responsibility for deciding how the company responds.
Evidence to keep: the approved assignment list, current role holders, decision limits, backup instructions, and dated departure records showing who requested, performed, and checked the work.
What this could look like at 100 people
At around 100 people, HR, IT, engineering, procurement, and application owners may all participate in access management. Employee departures and contractor departures often begin in different places. Give the overall process an owner who can resolve gaps across both paths.
HR could initiate employee departures while engagement owners initiate contractor departures. IT handles centrally managed accounts, and named application owners handle systems outside that coverage. A shared workflow records the required steps and sends incomplete or failed actions to the process owner.
Suppose a newly purchased support tool is missing from the departure workflow. The process owner assigns its removal step, confirms who administers the tool, and checks whether recent departures were affected. The tool’s ongoing owner then maintains the responsibility as the service changes.
Evidence to keep: the organization chart, department and application responsibilities, workflow assignments, escalation records, and actual completion records. Retain handovers when managers or control owners change.
What this could look like at 1000 people
A larger provider may operate through regional teams, product groups, and acquired businesses. Corporate reporting lines alone may not explain who administers a regional application or who can approve an exception to the company’s security standard.
Management could assign a corporate process owner to establish common expectations, with business-unit owners responsible for local operation. The arrangement should identify where local authority ends, how unresolved conflicts reach senior management, and which decisions require governing-body attention.
For example, an acquired company may continue using its own identity platform. Its local team performs departures and reports incomplete work to a named business-unit owner. The corporate owner receives enough detail to identify uncovered systems and coordinate remediation. Acquisition integration plans include a handover of those responsibilities.
Evidence to keep: current corporate and local responsibility records, delegation limits, provider assignments, integration handovers, and records of escalated decisions and their outcomes. Preserve approved local differences so reviewers can understand how the organization actually operates.
Test responsibilities against actual work
Choose a recent completed workflow and ask the owner and backup to trace it. Can they identify what triggered the work, who made the decisions, where the result was checked, and how an unresolved step would be escalated? Compare their answers with the procedure and system records.
You can also use a clearly labeled exercise to explore an absence or unusual event. Record what it reveals and assign corrections. An exercise can demonstrate preparation, but it should not be presented as evidence that a real departure was processed.
Revisit assignments when people leave, services change, providers change scope, or teams reorganize. Choose a periodic review frequency suited to the organization and document event-driven updates as they happen. A five-person company handling highly sensitive information may need stronger arrangements than a much larger company with a simpler service.
Retain evidence that matches the organization
Keep approved responsibility records and enough history to explain changes during the examination period. An owner list created at period-end cannot establish who performed a control months earlier. Dated workflow records, approvals, handovers, and escalations help connect the documented arrangement to actual activity.
Resolve contradictions among the chart, policy, supplier agreement, and ticket queue. If they assign different owners, clarify the decision and communicate the corrected responsibility. Collect evidence of the work as it happens, with its scope, date, performer, result, and follow-up where relevant.
Discuss evidence needs and appropriate access restrictions with the examining CPA firm. The auditor determines the procedures and evidence necessary for the examination; these examples do not guarantee an audit outcome.
Put responsibility into practice
Pick one workflow that would have serious consequences if it were missed. Ask the people involved to identify who initiates it, who decides, who performs the work, and who verifies completion. Resolve the gaps, then have the backup walk through the revised process.
CC1.2 addresses governance oversight. CC1.3 establishes how authority and responsibility are organized. The next article, CC1.4, will examine whether people have the competence needed for their roles; CC1.5 will address accountability for carrying them out.
Support for your SOC 2 program
Genius GRC helps organizations develop practical controls and organize supporting evidence. Discuss your SOC 2 needs with us to identify responsibilities and decision authority suited to your services, risks, and resources.
Explore the SOC 2 Guide for the full series.
This article provides general guidance. Adapt the examples to your examination scope and obligations with your advisers and auditor.