What CC1.3 SOC 2 requires for structures, reporting lines and authorities
CC1.3 asks management, under board oversight, to set up the organizational structure, reporting lines, and the authorities and responsibilities needed to pursue the company's objectives. It restates COSO Principle 3, and in a SOC 2 it is the control that proves someone owns each other control. When a customer asks for a SOC 2 and no one can show who approves access, who answers for incidents, or who signs off on vendor risk, the examiner has nothing to test in CC6, CC7 or CC9. The risk this criterion addresses is unclear ownership: controls that exist on paper but have no accountable person, or people who act without a defined authority to do so. Points of focus under CC1.3 include considering all structures of the entity, establishing reporting lines, defining and limiting authorities and responsibilities, and considering interactions with external parties such as vendors. These points of focus are not separate requirements, and not every one has to be addressed. What matters is that the structure you can show matches how the business actually runs.
Small and fast-moving teams find this hard for a predictable reason: one or two people hold most roles, and the org chart lives in someone's head or in a slide that is out of date. The first decision is to name a single owner for each control area, even where one person holds several titles, and to record who may approve production access, change deployments, accept risk and sign vendor contracts. Confirm with your examiner how they expect a shared role to be documented before you finalize it. The second check is consistency: the reporting lines in your org chart, your role definitions, your access groups and your ticket approval paths should tell the same story. Mismatches between these are among the first things a tester finds. Also decide which vendor and contractor relationships need named internal owners, since external parties appear in this criterion's points of focus.
Your evidence for CC1.3 is the current org chart with a date, written role descriptions with responsibilities and limits of authority, and records showing that the people named actually hold those authorities, such as access approvals and change approvals made by the designated owner. Where you keep these records matters less than whether they are versioned and can be reviewed over the audit period. Wiki tools with version history, such as XWiki's document version control, can keep dated role definitions with a record of who changed them and when. Permission models that tie abilities to assigned roles, such as the BookStack roles and permissions model, can mirror the authorities you document. Confirm with your CPA firm which format and level of detail it will accept, because the examiner decides what satisfies the criterion.
Which structures, roles and external parties are in scope for CC1.3
CC1.3 is only as good as the boundary it describes. The cards below cover the scoping decisions that change how much work the structure and authority evidence requires, and the people and organizations an assessor will expect to see inside that picture.
The system boundary
The org structure and role definitions must cover every team, product line and location that builds, runs or supports the system in scope. Start by drawing the boundary in the system description, then confirm that each in-scope function has a named owner, a reporting line and written authorities. A team left outside the boundary but still changing production is a common gap an assessor will find.
Teams that run in-scope controls
Every person who performs or approves a control needs a documented role that states what they decide, what they can approve and who they report to. Engineering, security, IT operations, support and finance often share duties on access reviews and change approvals. Confirm that the authorities written for each team match what people actually do in the tools, not only what the policy says.
Contractors and vendor staff with access
Contractors and vendor staff who hold production or administrative access act inside the organization's control environment, so their roles, sponsors and limits belong in the same structure record. Ask who approves their access, who reviews it and how it ends when the engagement does. Store these assignments in a system of record so the reporting line is visible to an assessor without manual reconstruction.
Subservice organizations
Cloud hosting, identity providers and other subservice organizations perform part of the system's operations, but management still owns the control environment around them. Document which party is responsible for each function, which SOC report covers it and who at your organization reviews that report. Be ready to explain the division of responsibility, because the boundary between your roles and theirs is where assessors probe.
Privacy points of focus when in scope
The 2017 criteria add points of focus to CC1.3 only when the privacy category is in scope, as the NIST crosswalk to the TSC flags. If privacy is included, confirm that the structure names who owns privacy decisions and how those authorities relate to the security roles. If privacy is out of scope, record that decision so the absence of these points is explained.
How an assessor tests CC1.3 across Type 1 and Type 2
A Type 1 report looks at CC1.3 as a design question: on a single date, is the organization structure, set of reporting lines and documented authorities suitable for the objectives of the system in scope? The assessor starts with a walkthrough, where management or the control owner explains how the structure was set, who approves what, and how a change to a role would reach the org chart. The assessor then inspects the org chart and role definitions as they stand on that date, checks that they cover the teams that build, operate and secure the system, and compares them with the written system description. Typical checks include:
- Org chart currency: the chart shows the people and reporting lines in place on the as-of date, with named owners for security, operations and privacy where those categories are in scope.
- Role definitions: each role states responsibilities and the authorities it holds, including limits on approval and spending.
- Vendor and external interfaces: documented responsibilities for outsourced parties, such as a managed hosting provider or a contract developer.
- Delegations: any authority passed to a deputy or team lead is written down, not just assumed.
- Board oversight link: the structure shows where the oversight body sits in relation to management.
The design stage rarely samples transactions. Findings here usually concern gaps in documentation, not failures in practice. Confirm with your auditor the exact as-of date and the evidence format they expect before you prepare the package.
A Type 2 report adds a test of operating effectiveness across an observation period set by the auditor and agreed in advance. For CC1.3, the assessor asks whether the structure was followed throughout that period, not only at its end. The walkthrough covers how changes to reporting lines were requested, approved and recorded, and who was responsible for keeping the chart current. The assessor then samples events and inspects the records that show authority was exercised within the documented limits. Typical testing includes:
- Sampled approvals: a selection of access grants, production changes, vendor contracts or spending approvals is traced to the approver and checked against the authority in the role definition.
- Authority limits: approvals above a documented threshold are shown to have reached the right level of management.
- Org chart changes: hires, departures and reassignments in the period are matched to updated charts and role records.
- Delegation use: any period when a deputy acted is covered by a written delegation that was in force.
- Timing: the assessor compares when a change took effect with when the record was updated.
Typical findings include outdated charts that lag behind staff moves, approvals given by someone whose role did not carry that authority, and delegations that were used but never written down. Ask your auditor how many samples they plan to take and which population they will draw from, so you can prepare complete records.
Both stages depend on evidence that can be inspected, dated and attributed. The assessor will look for the same kinds of artifacts in each stage, but the Type 2 test needs them for the whole period, not one date. Documentation tools with version history help here, because they show what a role definition said at a given time and who changed it. For example, a wiki that keeps page versions can show the role description that was in force during a sampled approval. Permission models in documentation or identity tools can also show who was entitled to act in a role. Useful evidence includes:
- Dated org charts: exported or versioned charts with a revision history.
- Role records: role definitions with an owner, an effective date and a review date.
- Approval logs: tickets or workflow records showing the approver and the time of approval.
- Delegation records: signed or logged delegations with start and end dates.
- Change history: evidence that each update was made by an authorized person.
Before the examination, check that every item can be produced for the full period and that no record exists only in someone's memory. Confirm with your auditor how they will treat evidence stored in tools you self-host, including how they will verify its integrity.
Evidence an assessor requests for CC1.3 and common findings
This table compares what an assessor asks for under CC1.3, what each artifact shows, and where organizations most often receive findings. Read each row as a pair: the document the organization maintains and the system record that should match it. The main takeaway is that an org chart only holds up when access rights and approvals in the systems agree with it.
| Evidence or test | What the assessor checks | Common finding |
|---|---|---|
| Current org chart with effective dates | Shows reporting lines for security, engineering, operations and support, with a date and version for each change | Chart is undated, or shows people who left or roles that were restructured months earlier |
| Role descriptions for control owners | Each person named as owner of a SOC 2 control has a written role covering that responsibility and its limits | Control owners named in the control matrix have no written role, or the role omits the control |
| Authority matrix | Who may approve access, production changes, vendor contracts, data disclosures and risk acceptances, and up to what limit | Matrix exists but is not approved by management, or it conflicts with approval practice in tickets |
| Delegation records | Temporary or standing delegations of authority, with scope, start and end dates, and the approver | Delegations made by email or chat with no end date and no record in the matrix |
| Change history of the chart and matrix | Versions showing what changed, when and who approved the change, with prior versions retained | No history kept, so the assessor cannot tell which version applied during the observation period |
| Sample comparison to system access | Assessor compares the chart with directory groups, production and admin roles, and approval rights in ticketing or deployment tools for sampled people | Staff with production or approval rights who do not appear in the matrix, or former employees with active access |
| Vendor and external party responsibilities | Named internal owners for each significant vendor relationship, reflecting the interactions with external parties the criterion covers | Vendor owned by no one, or the owner has left and no reassignment was recorded |
| Management review of structure | Evidence that management or the board reviewed reporting lines and authorities at a planned interval or after a major change | Restructuring occurred with no documented review, or review happened but produced no updated chart |
How to implement CC1.3 step by step
This sequence turns the COSO-based principle of structures, reporting lines and authorities into a documented, approved and testable org design that every other SOC 2 control can point back to.
Confirm the system boundary and in-scope services
Start by fixing what the examination covers: the product, the infrastructure it runs on, the people who build and operate it, and the teams that support customers. Management decides the boundary and writes it down in the system description, so every role you define has a clear place in the service. The output is a signed boundary statement listing in-scope systems, locations, teams and any subservice organizations. You know it is done when a reviewer can name which roles fall inside the boundary without asking anyone.
Draft the organizational structure and get approval
Management drafts the functional structure of the service organization, showing departments, teams, leadership layers and where security, engineering, operations and compliance sit. The draft goes to the board or equivalent oversight body, which reviews whether the structure supports the entity's objectives and whether oversight of internal control is clear. The output is a dated organization chart with the approval recorded in board or leadership minutes. Keep the approved version under version control so later changes can be compared against it.
Map reporting lines and escalation paths
Draw the reporting lines from each team to the accountable leader and then to the executive and board level. Add the escalation paths for security events, control failures and resourcing conflicts, and check that security and compliance have a route to leadership that does not run only through the team they review. The output is a reporting line map plus an escalation matrix. You know it is done when every role on the chart has one named manager and every escalation path ends at a named decision maker.
Write role definitions with defined and limited authorities
For each role, write a definition covering purpose, responsibilities, decisions the role may make, decisions it must refer upward and the limits on its authority. Examples include who may approve production changes, who may grant production access and who may accept a risk on behalf of the company. Management owns the content, and HR or the people lead confirms it matches employment records. The output is a role catalog with decision rights stated for each role. Confirm that no single role can both request and approve its own high-impact actions.
Map external parties and their interfaces
List the external parties that interact with the in-scope system or influence its controls, including cloud providers, managed service providers, contractors, auditors and critical vendors. For each one, name the internal owner, the interface (contract, integration, shared responsibility, support channel) and the authority the vendor has to act on your systems. Note where a vendor's own SOC report or assurance is relied upon. The output is an external party register tied to named owners. Confirm each owner accepts responsibility in writing.
Tie each role to access and approval rights
Convert the role definitions into the access model used by the systems. Map each role to the groups, permissions and approval workflows it needs in identity, cloud accounts, code repositories, deployment pipelines and ticketing tools, and remove any access that goes beyond the written authority. Record the mapping so an assessor can compare a sampled person's title, reporting line and granted access. The output is a role-to-access matrix with exceptions documented and approved. Confirm the matrix against a sample of live accounts before treating the step as complete.
Publish, communicate and review the structure
Publish the approved chart, role definitions and external party register in the internal wiki or policy repository, with a named owner and a review trigger such as a reorganization, a new subservice organization or a leadership change. Communicate the roles to staff and to the external parties who rely on them. Schedule a periodic review by management, with board oversight, and keep the review record. The output is a published, versioned structure with dated review evidence. You know it works when a new hire can find their role, manager and authorities without help.
Which evidence passes CC1.3 and how to keep it current
An auditor testing CC1.3 looks for a structure that is written down, approved by the right people, and still accurate on the day they sample it. The cards below cover the artifacts that carry that proof and the routines that keep them current between audits.
Versioned organization chart
The organization chart shows who reports to whom across engineering, security, operations and compliance, including any outsourced or contracted functions. Keep it in a system that records every edit with a date and an author, so the auditor can see the structure in force on the period dates. Check that the chart matches the HR system and access roster, since a mismatch is the first thing a sampling test exposes.
Role definitions and responsibilities
Each role needs a written description of its responsibilities for internal control, such as who owns access reviews, change approval or incident response. Store these in a wiki with version history so you can show what a role covered at a given date. Review them when job families change, not only at the annual audit.
Authority matrix
The authority matrix states who may approve spending, production access, vendor contracts, policy exceptions and changes to customer data handling, and where each limit sits. It is the document that makes the phrase *defined and limited authority* testable. Confirm that every approver named in the matrix holds the role they are approved for, and log any delegation with its start and end dates.
Board or committee approval minutes
Where a board or committee oversees security and internal control, its minutes should record review and approval of the org structure, the authority matrix and material changes to them. Minutes are the independent evidence that management's structure was actually considered by oversight. Keep the approved version and the date of approval, and ask your auditor which committee records they expect to see.
Reporting-line change records
Every promotion, transfer, reorganization or departure that changes a reporting line should generate a dated change record with the approver and the effective date. Tie these to the joiner and leaver workflow so changes do not depend on memory. Periodically compare the change log against the current chart to catch changes that were made in the directory but never documented.
Vendor and external party interaction records
CC1.3 covers how structure and authority extend to external parties. Keep records showing who owns each vendor relationship, who signs off on its security review, and who receives its incident notices. A current vendor register with named internal owners, reviewed on a set schedule, shows the auditor that responsibility did not stop at the company's edge.
Keeping org charts and authority records version controlled
An assessor testing CC1.3 wants to know what the organization's structure and authorities were on a given date, who approved each change and whether the record was ever altered after the fact. A current org chart alone cannot answer that. Keeping the structure, reporting lines and authority definitions in a wiki with full version history gives the organization a record of what changed, when and by whom, which is the evidence an examiner will ask for when reviewing a Type 2 observation period. Confirm with your auditor which dates and change events they will sample, because that decides how far back the history must reach.
XWiki, licensed under LGPL-2.1-or-later, keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. For an authority matrix, this means a reviewer can compare the version in force during the period with the one that followed and see exactly which approver or reporting line moved. Rollback should be restricted to a small group, and any rollback should itself be recorded as a change with a reason. Confirm that your chosen platform's history cannot be purged by page editors, since an editable history is not useful as audit evidence.
BookStack, licensed under MIT, assigns user abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. That lets you tie edit rights to the authority matrix: the people who may change a role definition or reporting line are the people the matrix names as owners of those decisions, and everyone else gets read-only access. Pairing this with the wiki history answers two questions at once, who was allowed to change the record and who actually did. Test the mapping before relying on it by asking a sample of staff to attempt edits they should not be able to make, and confirm that your version of the platform behaves as its documentation describes in your environment.
What meeting CC1.3 costs in money and effort
This table lists each cost component of meeting CC1.3, who carries it, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for building a quote: most of the cost is internal time, and the external spend is concentrated in design support and evidence upkeep. No prices or durations are given because none are supplied for this criterion, so ask each provider to price against the same written scope.
| Cost component | Who is paid or who carries it | One-time or recurring | Drivers and how to reduce cost |
|---|---|---|---|
| Internal time to design structure and roles | Internal leadership, HR and operations staff | One-time, then revised on change | Driven by headcount and the number of distinct functions. Reduce by reusing an existing org chart and writing role definitions once, in one place. |
| Board or leadership review time | Board members or executive team, unpaid time | Recurring, usually at least annually | Driven by how often the structure changes and how many reporting lines exist. Reduce by tying the review to an existing governance cycle. |
| Tooling or licenses for role and authority records | Software vendor, if a commercial GRC or HR tool is used | Recurring license fees | Driven by seat count and module choice. Self-hosted open-source wikis and access tools, such as XWiki or BookStack, remove license spend but need hosting and admin time. |
| Hosting and administration of self-hosted tools | Internal platform or IT team, or a managed service partner | Recurring | Driven by number of environments, backups and upgrade frequency. Reduce by standardizing one deployment and scheduling upgrades with other systems. |
| Evidence upkeep for reporting lines and authorities | Internal control owners | Recurring, continuous | Driven by change frequency such as joiners, leavers, role changes and vendor onboarding. Reduce by keeping version history in the tool rather than rebuilding records before each audit. |
| External review by a consultant | Consultant or implementation partner, under a written scope | One-time readiness, optional recurring check | Driven by org complexity, number of vendors and privacy category scope. Ask for a fixed-scope quote covering design, gap review and evidence walkthrough. |
| Auditor sampling and inquiry effort | CPA firm, billed under the engagement letter | Recurring each examination period | Driven by the number of samples the auditor selects and how quickly evidence is produced. Reduce by having current, dated role records ready before fieldwork begins. |
Where CC1.3 evidence usually falls short
Most CC1.3 findings do not come from missing intent. They come from an org chart that no longer matches reality, authorities that exist only in someone's head, and changes that leave no trace. The cards below pair each common gap with the step that closes it before the auditor asks.
Org chart out of date
The chart shows people who have left, omits newer teams, and places managers in the wrong reporting line. An auditor comparing the chart to access reviews and payroll records will see the mismatch quickly. Check that the chart is dated, has a named owner, and is reconciled against the HR system at a set frequency. Confirm the chart matches the current access list before fieldwork.
No written authorities
Teams often approve spending, production changes or customer data requests based on habit rather than a document that says who may approve what. Without a written matrix of authorities and their limits, the organization cannot show that approvals were within the granted power. Ask for a single document that lists each decision type, the role that holds it, and any dollar, data or system limits.
Approvals by people without authority
A common failure is an approval signed by a manager whose role was never granted that decision, or by someone who has since moved to another team. Sampling tests pick these cases up because the approver's name fails to match the authority matrix. Compare a sample of recent approvals against the matrix and note any approver whose authority was not assigned at the time.
Vendor interactions left undocumented
Decisions made in calls or chat with cloud providers, managed service providers and software vendors often bind the organization without a record of who agreed. CC1.3 expects the organization to consider how it interacts with external parties, so those touchpoints need an owner and a log. Assign a named internal owner to each material vendor and require that contract changes, escalations and scope decisions be recorded in the vendor file.
Role changes without records
When someone changes job, takes on an interim responsibility or leaves, the reporting line and authorities often change informally. Without a dated record, the auditor cannot tell who held a responsibility during the examination period. Require a short change record for each role move that states the old and new responsibilities, the effective date and the approver of the change.
Role definitions kept in the wrong place
Role descriptions stored in a shared folder with no version history tend to drift from what staff actually do. A wiki or documentation tool that keeps every change, records the author and allows comparison between versions gives the auditor a trail. Keep role definitions in a versioned knowledge base, restrict edit rights to the HR and security owners, and export the revision history for the examination period.
Who owns, who prepares and who attests CC1.3
Management owns the organizational structure that CC1.3 describes. Leadership decides how the company is divided, who reports to whom, and which authorities each role holds, and the board or equivalent oversight body reviews those decisions. No consultant can make these choices on the organization's behalf, and an auditor will ask who approved the structure and when. Your team therefore signs off on the final structure and keeps it current as the business changes.
- Decision rights: Management approves the organizational chart, the reporting lines and the list of delegated authorities, and records who approved each version.
- Role definitions: Leaders confirm that each role's responsibilities match what the person actually does for internal control, such as access approvals or change sign-off.
- Vendor relationships: Your team names the internal owner for each external party, including vendors and subservice organizations, and defines what that owner may approve.
- Review cadence: Management sets how often the structure is reviewed and triggers a review after reorganizations, hires into key roles or departures.
- Board involvement: Where a board oversees internal control, its minutes should show that it received and reviewed the structure.
Before engaging anyone, confirm that a named executive can explain every reporting line on the chart without notes.
An implementation partner can prepare the material that management reviews. This usually includes drafting the organizational chart from HR records, writing first versions of role descriptions, mapping authorities to the systems where they are enforced, and collecting the evidence that shows the structure works in practice. The partner prepares these artifacts. It does not decide the structure and does not issue any opinion on whether CC1.3 is met.
- Chart and role drafts: The partner may build the first version of the chart and role definitions from interviews and records, which management then edits and approves.
- Authority mapping: Engineers can show where permissions are granted in identity systems and wiki or documentation tools, so the written authorities match the technical ones.
- Evidence collection: The partner can set up recurring exports, such as versioned role pages or access-role listings, that show the structure over the audit period.
- Gap identification: A fixed-scope review can flag roles with no owner, or authorities granted outside the documented process, for management to resolve.
- Handover: Deliverables should be written so your staff can maintain them without the partner.
Ask the partner to state in the statement of work that management retains all decisions and that the partner does not provide an attestation.
The CPA firm performs the SOC 2 examination. It reads the description of the system, tests whether the CC1.3 controls were designed appropriately and, for a Type 2 report, whether they operated effectively over the period. The auditor reports its conclusion and must remain independent of the organization and of the parties that prepared its evidence. That independence is the reason the auditor cannot design the structure it is testing.
- Testing approach: The auditor compares the approved chart and role definitions with HR records, system access grants and sample transactions, then asks managers to explain their authority.
- Written representations: Management signs a representation letter confirming the structure and controls it described, so responsibility stays with the organization.
- Independence limits: A firm that drafted the chart or the role definitions may face a conflict when it tests them. Ask the firm how it handles that before engagement.
- Engagement terms: The engagement letter should state the audit scope, period and the auditor's responsibilities, separate from any preparation work.
- Report outcome: Only the CPA firm issues the SOC 2 report. No partner, consultant or tool vendor can issue one.
Before signing, confirm which tasks the firm will and will not perform for you, and get that boundary in writing.
Questions buyers ask about CC1.3 cost, effort and outside help
How much effort does CC1.3 take to meet in a SOC 2?
CC1.3 is a documentation and decision effort more than a technical one, and the size of the effort depends on how many roles, business units and external parties the organization has. The work is to define the structure, reporting lines and authorities, write them down, approve them and show they were followed. A single-product company with a few teams can often do this in a focused set of working sessions, while a larger group with several subsidiaries or outsourced engineering will need more mapping of who answers to whom. No fixed hours figure is supplied for this, so ask any advisor to break their estimate into role mapping, document drafting, approval and evidence collection, and to say which parts they expect your team to do.
Can a small team handle CC1.3 without outside help?
Yes, a small team can usually handle CC1.3 internally if one person owns the process and management is willing to make decisions on authorities. The points of focus ask for consideration of all structures of the entity, clear reporting lines, defined and limited authorities, and interactions with external parties such as vendors. A small company often has these answers in people's heads, so the main task is to write them down in a current org chart and role definitions, and to confirm that access and approval rights match those definitions. Outside help is most useful when the team lacks experience with how auditors test this, or when the same people would otherwise design and evaluate the controls.
How long does it take to get CC1.3 ready for an audit?
The timeline depends on how current the organization's structure documentation already is and how many changes have happened since it was last reviewed. Getting ready means approving a structure, publishing reporting lines and role definitions, and showing that they were in place on the relevant dates. For a Type 1 report, the structure must be right as of one date. For a Type 2 report, the auditor will look for evidence that the structure held over the whole observation period, so changes in roles need to be recorded as they happen. No duration is supplied for this work, so ask your auditor and any preparation partner to state the steps, dependencies and the period they expect to test before agreeing a schedule.
What does CC1.3 need from management and the board?
Under the criterion, management sets up the structures, reporting lines and authorities, and the board provides oversight, so both have visible roles. Management must decide the structure, assign responsibilities and approve the role definitions, then keep them current when people or products change. The board or equivalent oversight body should review that the structure supports the organization's objectives and that it is applied in practice. Smaller companies without a formal board can document who performs the oversight function and how it is evidenced, such as by meeting minutes or signed approvals. Confirm with your auditor how they expect oversight to appear in your specific entity.
Can a partner prepare the CC1.3 evidence for us?
An implementation partner can help prepare the structure documents, role definitions and the records that show authorities are applied, such as access approval workflows. DeployOpen prepares systems, controls and evidence for compliance assessments, and its work on CC1.3 would be to help set up the documentation in your environment and collect what the auditor will request. The organization still owns the structure and the decisions behind it. Only an independent CPA firm issues the SOC 2 report. Fixed scope, deliverables and timelines are agreed in writing before work starts, so ask for the list of documents and records to be delivered.
Can the same person prepare CC1.3 and also audit it?
No, the person preparing the evidence should not be the person who tests it. The auditor must be independent of the organization and the implementation partner, and the auditor's own work must be separate from the preparation of the system and controls. Internal staff can prepare the org chart and role definitions, and a partner can help with documentation, but the examination is performed by the independent CPA firm. Ask your auditor about independence requirements before engagement, and document who prepared each artifact so the audit trail is clear.
What ongoing work does CC1.3 create after the first report?
Once the structure is documented, the recurring work is keeping it accurate. Each hire, departure, reorganization, new vendor or change in authority should trigger an update to the org chart and role definitions, with approval recorded. Teams often review the structure on a fixed schedule as well as when changes occur, so the auditor can see that it stayed current across the period. Document changes in a versioned wiki or knowledge base help here, because the history of who changed what and when becomes evidence. Confirm the review frequency and approval steps with your auditor before the observation period starts.
How DeployOpen prepares CC1.3 evidence for your SOC 2
DeployOpen prepares the systems and records that show how your organization's structures, reporting lines and authorities are set and kept current, but your management owns those decisions and an independent CPA firm alone issues the SOC 2 report. Before work starts, we agree the scope in writing: which entities, systems, teams and external parties are covered, and which deliverables we will produce. That written scope is the boundary for everything below. DeployOpen does not issue reports, attestations or certifications.
In your own infrastructure, we help configure the tools that hold the structure as records. In a self-hosted wiki such as XWiki, we set up the organization chart, role definitions and authority matrices as versioned pages, so the history of who approved what and when is retained and can be compared between versions. In BookStack, we map each role to the permissions it needs, using role assignments and per-shelf, book or page overrides only where a documented decision requires them, so a reviewer can trace a user's abilities back to a named role. We also document how vendors and other external parties are placed in the reporting structure, including who owns each vendor relationship.
Before the auditor arrives, you should confirm three things: that the board or equivalent oversight body has approved the structure and its authority limits, that a named individual owns each role definition, and that the points of focus for CC1.3 that apply to your engagement have been considered, including any privacy-related points if the privacy category is in scope. DeployOpen can produce draft role definitions, authority matrices and a review schedule for your management to approve, but the approval and the judgments inside them remain yours. For the auditor's view of how these records are tested, see the AICPA 2017 Trust Services Criteria.
