Asset, Data & Architecture
Critical data flows, repositories, integrations, trust boundaries, customer-data processing paths, and AI/LLM data flows are documented and maintained.
Use this guide to put the control into operation, decide what records to retain, and check that an auditor can trace the evidence back to the work your team performed.
Maintained by GreenHat Security · Reviewed August 21, 2026
Engineers, security, and privacy reviewers can follow critical information from collection through processing, storage, integration, and exit, including trust boundaries, customer-data paths, and any AI or language-model processing.
First SOC 2 program
Create a system-context diagram and a data-flow view for each customer-facing product. Mark production boundaries, major repositories, external integrations, administrative paths, and where customer data enters and leaves; review them with an engineer who operates the service.
As the company scales
Maintain diagrams and integration records in a versioned architecture repository, assign them to service owners, and make updates part of architecture and production-change review. Use cloud, API, data-catalog, and infrastructure records to challenge whether the diagrams remain complete.
Define the customer-facing services, production environments, supporting platforms, external parties, and administrative interfaces covered by each view.
You should end up with: A scoped system-context diagram with named boundaries and owner.
Follow customer data, telemetry, authentication data, support exports, and other critical information from ingress to stores, processors, backups, and egress.
You should end up with: A data-flow diagram with data categories, direction, and repositories labeled.
Identify network and tenant boundaries, privileged paths, encryption transitions, key dependencies, logging points, and cross-environment movement.
You should end up with: Annotated diagrams showing trust boundaries and major safeguards.
Document third-party APIs, subprocessors, support tools, analytics, model providers, retrieval stores, and the data each receives or returns.
You should end up with: An integration inventory linked to the relevant diagram and data categories.
Have service owners compare diagrams with cloud resources, deployments, configuration, data stores, and current integrations, then resolve discrepancies.
You should end up with: A dated review record with corrections and owner approval.
Require architecture and data-flow impact to be considered for new services, repositories, integrations, and material production changes.
You should end up with: Change records linking to revised diagrams or documenting no impact.
Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.
Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.
Documents that define the control, its scope, ownership, and expected way of working.
Confirm what the record proves
Shows the current service components, environments, external dependencies, administrative paths, and trust boundaries that make up the scoped system.
Include this context
service and environment scope
Include this context
components and repositories
Include this context
external dependencies
Include this context
trust boundaries
Include this context
owner
Include this context
version or review date
Weak evidence to avoid
An undated sales architecture picture with product logos but no environments, data stores, trust boundaries, owner, or revision history.
Confirm what the record proves
Shows how named customer and sensitive data categories move from collection through processing, storage, integration, backup, and exit.
Include this context
data category
Include this context
source and destination
Include this context
flow direction
Include this context
repository or processor
Include this context
trust-boundary crossing
Include this context
version or review date
Weak evidence to avoid
Arrows between services with no data categories, direction, third parties, backup path, or customer-data distinction.
Confirm what the record proves
Shows the active internal and third-party connections, their owners, the data exchanged, and whether model, analytics, support, or subprocessor paths are represented.
Include this context
integration and owner
Include this context
source and destination systems
Include this context
data categories and direction
Include this context
business purpose
Include this context
authentication or transfer method
Include this context
lifecycle status
Weak evidence to avoid
A vendor list that does not identify active interfaces, transferred data, direction, owner, or disabled connections.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
Shows that material service, repository, integration, or data-use changes were checked for architecture and data-flow impact and caused updates where needed.
Include this context
change identifier and date
Include this context
affected service or data path
Include this context
impact decision
Include this context
reviewer
Include this context
diagram or inventory revision
Include this context
deployment status
Weak evidence to avoid
A deployment ticket that names code changes but contains no architecture impact decision or link to revised documentation.
Type 1
The current approved architecture views, data-flow diagrams, and active integration inventory for every scoped customer-facing service on the examination date, including known documentation gaps.
Type 2
Every production change during the review period that added or materially changed a service, repository, integration, trust boundary, customer-data path, or model-processing path, plus every scheduled quarterly production documentation review and annual supporting-system review.
Compare period production deployments, cloud resource additions, API registrations, integration enablements, and data-catalog changes with architecture-impact decisions; then map every active scoped service and integration to a current owned diagram and investigate unmatched changes or components.
Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.
Determine whether the control is designed to achieve this result: Engineers, security, and privacy reviewers can follow critical information from collection through processing, storage, integration, and exit, including trust boundaries, customer-data paths, and any AI or language-model processing.
Compare the documented owner with the intended role (Engineering / Infrastructure / Data Owner), then compare dated records with the stated cadence: Quarterly for production/customer-impacting; annually for supporting assets.
Compare period production deployments, cloud resource additions, API registrations, integration enablements, and data-catalog changes with architecture-impact decisions; then map every active scoped service and integration to a current owned diagram and investigate unmatched changes or components.
The current approved architecture views, data-flow diagrams, and active integration inventory for every scoped customer-facing service on the examination date, including known documentation gaps.
Every production change during the review period that added or materially changed a service, repository, integration, trust boundary, customer-data path, or model-processing path, plus every scheduled quarterly production documentation review and annual supporting-system review.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates Shows the current service components, environments, external dependencies, administrative paths, and trust boundaries that make up the scoped system.
For each selected record, confirm it demonstrates Shows how named customer and sensitive data categories move from collection through processing, storage, integration, backup, and exit.
For each selected record, confirm it demonstrates Shows the active internal and third-party connections, their owners, the data exchanged, and whether model, analytics, support, or subprocessor paths are represented.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates Shows that material service, repository, integration, or data-use changes were checked for architecture and data-flow impact and caused updates where needed.
Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.
These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.
Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.