Asset, Data & Architecture
Assets critical to service delivery, customer isolation, detection integrity, privileged access, evidence generation, recovery, or customer commitments are tagged as critical/high-value and reviewed based on risk.
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
Assets whose failure or compromise would materially affect service delivery, customer isolation, privileged access, detection, recovery, evidence, or commitments are visibly tagged, owned, and reviewed according to risk.
First SOC 2 program
Use the asset inventory and architecture to identify a focused set of crown-jewel services, identity systems, production data stores, security sensors, deployment systems, recovery components, and customer-isolation mechanisms. Record why each is critical and who owns it.
As the company scales
Represent criticality in the service catalog, cloud tags, and infrastructure code; use dependency data to identify supporting high-value targets; and drive stronger review, monitoring, recovery, change, and access expectations from the tag.
Describe the service, security, customer, recovery, and commitment impacts that qualify an asset as critical or high-value, including dependency and concentration considerations.
You should end up with: Approved criticality criteria with examples and decision owner.
Review service dependencies, data flows, privileged paths, detection sources, deployment systems, recovery components, and customer-isolation mechanisms.
You should end up with: A candidate list with impact rationale and supporting architecture links.
Have service and security owners confirm the designation and apply a consistent tag in the governed inventory and, where possible, the source platform.
You should end up with: A critical asset register with owner, tag, rationale, and approval date.
Map each critical asset to stronger access, monitoring, change, recovery, vulnerability, and review activities appropriate to its risk.
You should end up with: An asset-to-safeguard mapping with service and recovery objectives.
Compare critical services with their identity, network, data, key, deployment, observability, and vendor dependencies to identify untagged concentration points.
You should end up with: A dependency review with new tags or documented exclusions.
Reassess designations after material architecture changes and on the chosen risk-based cadence, removing tags only with documented approval.
You should end up with: Dated owner reviews, changes, and remediation tickets.
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 approved population of assets whose compromise or failure could materially affect service, isolation, detection, privileged access, evidence, recovery, or commitments.
Include this context
stable asset or service identifier
Include this context
owner
Include this context
criticality designation
Include this context
impact rationale
Include this context
dependencies
Include this context
approval and review date
Weak evidence to avoid
A list of crown jewels with friendly names but no asset identifiers, owners, rationale, dependencies, or approval dates.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
Shows that service and security owners reassessed the designation, rationale, dependencies, and operational safeguards for the reviewed asset population.
Include this context
reviewed population and snapshot
Include this context
owner and reviewer
Include this context
designation decision
Include this context
dependency changes
Include this context
safeguard gaps
Include this context
review date and actions
Weak evidence to avoid
A manager approval that does not identify the reviewed assets, dependencies, changed designations, or resulting actions.
Confirm what the record proves
Shows why review depth and frequency were appropriate to asset risk and how identified access, monitoring, change, recovery, or concentration concerns were resolved.
Include this context
asset and risk factors
Include this context
review frequency or trigger
Include this context
review procedures
Include this context
findings
Include this context
risk owner decision
Include this context
remediation status
Weak evidence to avoid
A quarterly calendar event with no asset scope, risk factors, procedures, findings, or owner decision.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
Shows that the high-value designation is applied to the live cloud, service, configuration, or monitoring object rather than existing only in a narrative document.
Include this context
source-system asset identifier
Include this context
tag key and value
Include this context
environment
Include this context
owner tag
Include this context
tag applied or observed date
Weak evidence to avoid
A screenshot of one tagged resource without its stable identifier, environment, export scope, owner, or evidence that other register entries are tagged.
Type 1
The current critical asset register and live source-system tags on the examination date, including dependencies, safeguard mappings, and open criticality or tagging exceptions.
Type 2
Every critical or high-value designation added, changed, or removed during the review period, every material architecture or dependency change affecting a critical asset, and each scheduled risk-based owner review due in the period.
Compare critical-service dependencies and material architecture changes with the register, then reconcile every register entry to live cloud, service, and monitoring tags; investigate untagged dependencies, orphan tags, unexplained designation changes, and overdue risk-based reviews.
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: Assets whose failure or compromise would materially affect service delivery, customer isolation, privileged access, detection, recovery, evidence, or commitments are visibly tagged, owned, and reviewed according to risk.
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 critical-service dependencies and material architecture changes with the register, then reconcile every register entry to live cloud, service, and monitoring tags; investigate untagged dependencies, orphan tags, unexplained designation changes, and overdue risk-based reviews.
The current critical asset register and live source-system tags on the examination date, including dependencies, safeguard mappings, and open criticality or tagging exceptions.
Every critical or high-value designation added, changed, or removed during the review period, every material architecture or dependency change affecting a critical asset, and each scheduled risk-based owner review due in the period.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates Shows the approved population of assets whose compromise or failure could materially affect service, isolation, detection, privileged access, evidence, recovery, or commitments.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates Shows that service and security owners reassessed the designation, rationale, dependencies, and operational safeguards for the reviewed asset population.
For each selected record, confirm it demonstrates Shows why review depth and frequency were appropriate to asset risk and how identified access, monitoring, change, recovery, or concentration concerns were resolved.
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 the high-value designation is applied to the live cloud, service, configuration, or monitoring object rather than existing only in a narrative document.
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.