System Operations
Infrastructure, cloud resources, containers, endpoints, applications, external-facing services, and supporting components are scanned or assessed for vulnerabilities and misconfigurations based on risk and cadence.
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
In-scope infrastructure, applications, endpoints, containers, and cloud resources receive appropriate vulnerability coverage, and missing or failed scans are visible rather than silently accepted.
First SOC 2 program
Begin with internet-facing services, cloud configuration, production images and dependencies, and company endpoints. Use authenticated or context-aware scanning where possible and reconcile results to a simple asset list.
As the company scales
Drive scanner enrollment from asset discovery and deployment pipelines, set risk-based scan methods and timing, measure coverage, and route new findings with asset ownership and business context.
List in-scope asset types, environments, owners, exposure, and approved assessment methods, including systems that cannot use a standard scanner.
You should end up with: Risk-ranked vulnerability coverage plan
Use credentials, agents, build integrations, or cloud APIs where appropriate so checks can see configuration and software that an external probe would miss.
You should end up with: Scanner configuration tied to asset classes
Run checks on a documented schedule and at useful lifecycle points such as new deployments, image publication, major changes, or asset enrollment.
You should end up with: Scan schedule and pipeline triggers
Compare expected assets with scanner enrollment and successful results; assign blind spots, stale agents, failures, and exclusions to owners.
You should end up with: Coverage report with explained exceptions
Send actionable findings to the remediation process with asset, severity, detection date, owner, and source, while retaining reports needed to show coverage over time.
You should end up with: Traceable finding records and period scan history
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
Every in-scope asset or asset class has an owner, required assessment method and timing, current enrollment status, and latest successful result.
Include this context
Asset identifier
Include this context
Environment and class
Include this context
Owner
Include this context
Required method and timing
Include this context
Latest successful run
Include this context
Coverage status or exception
Weak evidence to avoid
A scanner asset count that cannot be reconciled to the company's in-scope cloud, endpoint, application, and container population.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
Assets that cannot use the standard scan path receive an approved alternative assessment with equivalent visibility, ownership, and follow-up.
Include this context
Excluded asset or class
Include this context
Reason standard scan is unsuitable
Include this context
Alternative method
Include this context
Assessor and date
Include this context
Result
Include this context
Next assessment or review
Weak evidence to avoid
A permanent scanner exclusion that says unsupported with no alternative check, owner, result, or review date.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
A defined scanner assessed an identifiable asset scope at a known time and retained both successful coverage and resulting findings.
Include this context
Scan run ID
Include this context
Scanner and method
Include this context
Asset or scope
Include this context
Start and completion time
Include this context
Run status
Include this context
Finding summary
Weak evidence to avoid
A findings-only PDF with no scan run ID, covered assets, completion status, or evidence that the planned scan finished.
Confirm what the record proves
A defined application, service, or environment received a scoped hands-on assessment and its findings entered accountable remediation.
Include this context
Assessment scope
Include this context
Test dates
Include this context
Tester
Include this context
Methods or scenarios
Include this context
Findings
Include this context
Remediation references
Weak evidence to avoid
A cover letter stating that testing occurred without scope, dates, methods, findings detail, or links to remediation decisions.
Type 1
The current in-scope asset-to-assessment inventory, active scanner and trigger configuration, latest completed scan or approved alternative assessment for each covered class, and a recent asset-to-coverage reconciliation.
Type 2
Every scan run or approved alternative assessment expected from the documented schedule or lifecycle trigger for each in-scope asset or asset class during the review period, including completed, failed, missed, cancelled, and rescheduled runs, plus every scheduled asset-to-scanner coverage reconciliation due during the period.
For each period asset-inventory snapshot, derive the scans or alternative assessments expected from its method, cadence, and deployment triggers; reconcile that expected list to immutable scanner run histories and assessment records, then reconcile covered asset identifiers back to the inventory and explain every missing asset, missed run, failed run, duplicate, and approved exclusion.
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: In-scope infrastructure, applications, endpoints, containers, and cloud resources receive appropriate vulnerability coverage, and missing or failed scans are visible rather than silently accepted.
Compare the documented owner with the intended role (Security Operations / Engineering / Infrastructure), then compare dated records with the stated cadence: Continuous/ongoing; periodic review by risk.
For each period asset-inventory snapshot, derive the scans or alternative assessments expected from its method, cadence, and deployment triggers; reconcile that expected list to immutable scanner run histories and assessment records, then reconcile covered asset identifiers back to the inventory and explain every missing asset, missed run, failed run, duplicate, and approved exclusion.
The current in-scope asset-to-assessment inventory, active scanner and trigger configuration, latest completed scan or approved alternative assessment for each covered class, and a recent asset-to-coverage reconciliation.
Every scan run or approved alternative assessment expected from the documented schedule or lifecycle trigger for each in-scope asset or asset class during the review period, including completed, failed, missed, cancelled, and rescheduled runs, plus every scheduled asset-to-scanner coverage reconciliation due during the period.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates Every in-scope asset or asset class has an owner, required assessment method and timing, current enrollment status, and latest successful result.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates Assets that cannot use the standard scan path receive an approved alternative assessment with equivalent visibility, ownership, and follow-up.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates A defined scanner assessed an identifiable asset scope at a known time and retained both successful coverage and resulting findings.
For each selected record, confirm it demonstrates A defined application, service, or environment received a scoped hands-on assessment and its findings entered accountable remediation.
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.