Overview
System Description Maintenance is the process of creating, reviewing, and updating the formal description of an organization’s systems, boundaries, data flows, and controls for SOC 2 reporting. It ensures the system description remains accurate, complete, and aligned with current operations to meet CC2.1 communication requirements.
Step-by-Step Process
Identify system scope
The Engineering Lead reviews the SOC 2 scope to confirm which applications, infrastructure components, and third-party services are in scope. This includes validating system boundaries, user types, and data classifications. The output is a confirmed in-scope system list for the current period.
Role: Engineering Lead
Collect current architecture details
The Engineering Lead gathers up-to-date architecture diagrams, infrastructure inventories, and service dependencies from engineering documentation and cloud consoles. Any changes since the last audit (new services, migrations, deprecations) are noted. The output is a consolidated set of current-state technical inputs.
Role: Engineering Lead
Review prior system description
The prior year’s SOC 2 system description is reviewed line by line to identify outdated or missing information. Changes in data flows, control ownership, or system components are marked for update. The output is an annotated version highlighting required revisions.
Role: Engineering Lead
Update system narrative
The Engineering Lead updates the system description narrative to reflect the current environment, including infrastructure, software, people, processes, and data flows. Language is written in auditor-facing terms and aligned to SOC 2 CC2 criteria. The output is a revised system description draft.
Role: Engineering Lead
Update architecture diagrams
System diagrams are updated to visually match the written description, showing data flows, trust boundaries, and third-party integrations. Diagrams are versioned and dated to reflect the review period. The output is an updated diagram set linked to the description.
Role: Engineering Lead
Perform internal review
The revised system description is reviewed by Security or Compliance for completeness and consistency with other SOC 2 artifacts. Feedback is incorporated, and discrepancies are resolved. The output is an internally approved system description.
Role: Security Analyst
Approve and publish description
The Engineering Lead formally approves the final system description and publishes it in the designated documentation repository. Access permissions are confirmed, and the approval date is recorded. The output is an approved, accessible system description for audit use.
Role: Engineering Lead
What You Need Before Starting
- Prior year SOC 2 system description document
- Current system architecture diagrams
- Inventory of in-scope applications and infrastructure
- Access to documentation tools (Confluence, Notion, Lucidchart)
- SOC 2 scope definition and boundaries
Evidence Your Auditor Expects
- Final system description document with approval date and version history
- Annotated prior-year system description showing tracked changes and review date
- Updated architecture diagram exported with timestamp (PDF or PNG)
- Internal review comments or approval record dated within the audit period
How This Looks In Your Tools
Confluence
Navigate to the relevant Space and select the page where the system description is maintained, or click “Create” → “Page” to start a new document. Use the page tree to place it under the SOC 2 or Compliance section, and add a clear page title with the audit year.
Use the Confluence editor to update narrative sections and insert diagrams via “Insert” → “Files and images” or by embedding Lucidchart diagrams. Apply the “Page Properties” macro to record owner, last review date, and version. Once finalized, click “Publish” and use “Restrictions” to confirm read access for auditors.
Notion
Open the Compliance or SOC 2 workspace and navigate to the System Description page, or click “New page” to create one. Use headings to structure sections such as Infrastructure, Data Flows, and Third Parties, and update text inline to reflect current systems.
Embed diagrams by selecting “/embed” and pasting the Lucidchart or image link. Add a properties table at the top with fields for Owner, Last Reviewed Date, and Approval Status. Once approved, ensure the page is shared with audit-read access via the “Share” menu.
Lucidchart
Log in to Lucidchart and open the existing system architecture diagram from the Documents dashboard, or select “New” → “Blank Diagram” to create one. Update shapes and connectors to reflect current infrastructure, data flows, and third-party integrations.
Use “File” → “Version History” to confirm changes are saved with timestamps. Export the final diagram via “File” → “Export” → PDF or PNG, and name the file with the audit year and export date before linking or uploading it to the system description document.
Common Audit Findings
- Outdated system description
- This occurs when teams reuse prior-year descriptions without validating changes in the environment. Prevent this by performing a documented annual review and explicitly comparing against current architecture and inventories.
- Mismatch between diagrams and narrative
- Auditors often find inconsistencies when diagrams are updated but text is not, or vice versa. Prevent this by updating diagrams and narrative together and reviewing them side by side during internal review.
- Missing approval evidence
- Organizations sometimes fail to document formal approval of the system description. Prevent this by recording approval dates, approver names, and version history directly in the documentation tool.
- Incomplete system scope
- Key systems or third-party services may be omitted due to unclear scope definitions. Prevent this by validating the system list against the official SOC 2 scope and vendor inventory each year.