SOC 2 CC1.3: Structures, Reporting Lines, and Authorities

SOC 2 CC1.3 requires management, with board oversight, to set up the organizational structures, reporting lines, and authorities the business needs to pursue its objectives, including its security objectives. It sits in the middle of the CC1 Control Environment series, and a frequent finding under it is a company whose documented org structure and authority assignments describe a template it adopted rather than how the business runs.

What does SOC 2 CC1.3 require?

In plain terms, CC1.3 asks whether the organization has a defined shape and whether the people inside it know who is responsible for what. Management draws the structure, the board oversees it, and the result is a set of reporting lines and authority assignments that everyone can point to. Security responsibilities are part of that picture, not a separate diagram off to the side.

CC1.3 maps to COSO Principle 3, which covers how an entity organizes itself to pursue its objectives. The criterion is broader than a single security-manager job description. It expects the structure to account for every part of the entity, operating units, legal entities, geographies, and outsourced providers, and it expects authority for security matters to be assigned deliberately rather than assumed.

The practical test an auditor applies is simple to state. Can the organization show who holds security authority, who reports to whom, and where duties are separated so that no single person can both perform and approve a sensitive action. When the answer lives only in people's heads or in a diagram that no longer matches the business, CC1.3 is the criterion that surfaces it.

What are the CC1.3 points of focus?

The AICPA defines 5 points of focus for CC1.3. Because the Trust Services Criteria are AICPA copyrighted material, the points of focus below are paraphrased and grouped by theme rather than reproduced verbatim; consult the official TSC document for exact wording.

• Considers all structures of the entity. Management accounts for the full shape of the organization when it designs structures, including operating units, legal entities, geographic locations, and outsourced service providers.
• Establishes reporting lines. Each structure has defined reporting lines so that authority and accountability flow to identifiable people and information moves to where decisions are made.
• Defines, assigns, and limits authorities and responsibilities. Roles carry specific authorities and responsibilities that are bounded rather than open-ended, and duties are segregated so that no individual controls an entire sensitive process.
• Addresses security-specific requirements (TSC). When authorities and responsibilities are defined, the security, availability, processing integrity, confidentiality, and privacy requirements relevant to the entity are built into those role definitions.
• Considers interactions with external parties (TSC). Structures and reporting lines account for how the entity interacts with external parties, so that responsibility for those interactions is assigned rather than left to chance.

How do you meet CC1.3 in cloud environments?

Cloud environments meet CC1.3 by documenting the security organization and enforcing separation of duties in the identity and access layer:

• A current organizational chart. The org chart names operating units, teams, and reporting lines, and it is kept current as the company grows rather than being drawn once at the start of the audit.
• Job descriptions with security responsibilities. Roles that carry security duties, whether an ISM, a security lead, or an engineering manager, have those responsibilities written into their job descriptions rather than implied.
• Named security authority. A specific role holds authority over the security program, with its scope documented, so an auditor can see who owns security decisions.
• Segregation of duties in IAM. Cloud IAM roles and group memberships are structured so that the person who requests access is not the person who approves it, and production changes require a separate approver, with the role design itself standing as evidence.
• Reporting lines for outsourced providers. Where managed service providers or contractors handle part of the environment, the structure records who inside the company owns that relationship and the security expectations attached to it.

How do you meet CC1.3 on-prem?

On-prem environments apply the same structure and separation of duties where the work runs on owned infrastructure and directory services:

• A documented org structure and directory. Reporting lines are recorded in an org chart and reflected in directory group membership, so the on-paper structure and the access structure agree.
• Role definitions with security duties. System administrators, network owners, and physical-security custodians have their security responsibilities defined in role documentation.
• A designated security role. A security manager or equivalent holds documented authority over the program, including on-premise systems and facilities.
• Segregation of duties across systems. Duties are separated so that, for example, the administrator who provisions a server is not the sole approver of its access grants, with compensating controls documented where team size makes full separation impractical.
• Assigned ownership of external interactions. Responsibility for interactions with vendors, auditors, and other external parties is assigned to named roles rather than handled ad hoc.

Cloud vs on-prem at a glance

What evidence do auditors expect for CC1.3?

How does CC1.3 map to ISO 27001:2022?

The overlap is partial because A 5.2 and A 5.4 focus on defining and assigning security roles and holding management responsible for them, while CC1.3 also reaches segregation of duties and the broader design of entity structures and reporting lines. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across all five Trust Services Categories.

Related criteria

CC1.3 builds on the board oversight established in CC1.2: the board that CC1.2 requires is the same board that oversees the structures and authorities CC1.3 puts in place. Once roles and authorities are assigned, CC1.4 asks whether the people filling them are competent to carry the responsibilities. Together the CC1 series describes how an organization sets up its control environment before any technical control is built.

Frequently Asked Questions

What does SOC 2 CC1.3 mean?

SOC 2 CC1.3 requires management, with board oversight, to establish organizational structures, reporting lines, and appropriate authorities and responsibilities in pursuit of the entity's objectives. In practice it means the company has a documented structure, defined reporting lines, assigned and bounded authorities that include security responsibilities, and segregation of duties so no one person controls an entire sensitive process. It is the third criterion in the CC1 Control Environment series and maps to COSO Principle 3.

What evidence satisfies CC1.3?

The core evidence is a current organizational chart, job descriptions that spell out security responsibilities, documentation of the security-manager or ISM role and its authority, a segregation-of-duties matrix or the IAM role design that enforces it, and records showing who owns interactions with outsourced providers and other external parties. Together these show that structures, reporting lines, and authorities are defined, assigned, and matched to the real organization.

How does CC1.3 handle segregation of duties?

CC1.3 expects authorities and responsibilities to be defined, assigned, and limited, and one point of focus specifically covers segregating duties so that no single individual can both perform and approve a sensitive action. In cloud environments this usually shows up in IAM role design, where the person who requests access is not the person who approves it. Where team size makes full separation impractical, the organization documents compensating controls rather than leaving the gap unexplained.

How is CC1.3 different from CC1.2?

CC1.2 covers board independence and oversight of internal control. CC1.3 covers the structures, reporting lines, and authorities that management establishes under that oversight. CC1.2 is about who watches the control environment, and CC1.3 is about how the organization is shaped so that authority and responsibility, including for security, reach identifiable people.

Does CC1.3 apply to a company without a formal org chart?

Yes. CC1.3 applies to any entity seeking a SOC 2 report, regardless of size. A small company still needs to show its structure, reporting lines, and who holds security authority, even if that means a simple chart plus role documentation rather than a large hierarchy. The criterion cares that the structure is defined and matches how the business actually runs, not that it looks like a large enterprise.