Automated Testing and Security Scanning for SOC 2

What this control should accomplish

Production candidates run the applicable functional and security checks, and failures block release unless a documented exception is approved.

How to implement Automated Testing and Security Scanning

1. 1

   Choose applicable checks

   Map each application, infrastructure, image, and configuration path to the functional and security checks it needs before release.

   You should end up with: Pipeline control matrix by change path

2. 2

   Enforce pipeline gates

   Configure required checks so failed, skipped, or missing results prevent the candidate revision from progressing.

   You should end up with: Required-check and blocking-rule configuration

3. 3

   Control exceptions

   Record the failed check, risk, compensating action, approver, affected revision, and expiry before any bypass.

   You should end up with: Time-bound scanning exception record

4. 4

   Retain results

   Keep test and scan summaries with commit, build, and release identifiers long enough to support period review.

   You should end up with: Searchable results tied to deployed builds

Evidence to keep, and what it should prove

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.

Which records should you prepare for the audit?

How an auditor may test this control

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.

• Confirm the intended control outcome

  Determine whether the control is designed to achieve this result: Production candidates run the applicable functional and security checks, and failures block release unless a documented exception is approved.

• Confirm ownership and operating cadence

  Compare the documented owner with the intended role (Head of Engineering / Platform Owner), then compare dated records with the stated cadence: Per change.

• Establish the complete audit record set

  Begin with production deployments, resolve each artifact to its pipeline, compare expected checks from pipeline configuration with actual jobs, and reconcile every missing or non-passing result to an approved exception or blocked release.

• Prepare the as-of-date evidence for a Type 1 engagement

  Retain the required pipeline and scanner configuration plus one recent production release showing all applicable checks, results, and any exception on the selected date.

• Prepare period evidence for a Type 2 engagement

  For every production release attempt during the period, list each required functional and security check and its result, including failed, cancelled, skipped, rerun, emergency, and exception-approved paths.

• Inspect the approval / review evidence

  Records showing that an accountable person reviewed, approved, challenged, or accepted the work.

  • Inspect exception records

    For each selected record, confirm it demonstrates A failed, skipped, or unavailable check was assessed and approved with bounded scope, compensating work, and expiry.

    • Exception ID
    • Failed or skipped check
    • Affected release
    • Risk decision
    • Approver
    • Expiry and remediation

• Inspect the operating / technical evidence

  Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.

  • Inspect CI/CD test results

    For each selected record, confirm it demonstrates The exact production candidate ran its required functional tests and the release decision reflects the result.

    • Pipeline ID
    • Commit or artifact
    • Test suite
    • Execution time
    • Result
    • Release environment

  • Inspect SAST/dependency/secret/IaC/container scan results

    For each selected record, confirm it demonstrates Applicable security scanners evaluated the released code, dependencies, credentials, infrastructure, or images against defined gates.

    • Scanner and rule set
    • Commit or artifact
    • Scope
    • Execution time
    • Findings by severity
    • Gate result

• Trace the control from design to operation

  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.

Common implementation and evidence gaps

• Scanners run on a schedule but not on the revision being released.
• A failed check warns the engineer but does not block deployment.
• Results expire before the review period can be reconstructed.
• Exceptions lack an owner, rationale, or expiration date.

Before you call this control ready

• Can a failed required check prevent the exact candidate from deploying?
• Are scanner configurations and severity thresholds version-controlled?
• Can a release be traced to its functional and security results?
• Are active exceptions reviewed and closed by their expiry dates?

Trust Services Criteria references

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.

• CC7.1
• CC8.1

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.

Related controls to review next