What CC7.1 asks SOC 2 organizations to detect
CC7.1 asks the organization to run detection and monitoring procedures that find two things: configuration changes that introduce new vulnerabilities, and exposure to vulnerabilities that were disclosed after the system was deployed. In practice, an assessor will want to see that the organization knows what its systems are supposed to look like, notices when they drift from that baseline, and knows when a newly published flaw affects something it runs. The risk is straightforward. A server hardened last year can be reopened by a single emergency change, a container image can pick up a vulnerable library, or a managed database can be left with a permissive setting, and none of this shows up unless something is looking for it.
The difficulty comes from three places. Inventory drifts constantly as hosts, containers, cloud resources, browser extensions and third-party agents are added and retired, so a list compiled at audit preparation is stale within weeks. The component types differ widely, which means operating system packages, application dependencies, Kubernetes objects and cloud configurations each need their own detection path. And scan cadence matters: a vulnerability database updated daily can make a scan from last month misleading. Before fieldwork, ask your auditor which population and which component types they expect you to cover, and confirm with your team how a newly disclosed vulnerability reaches a ticket.
Because CC7.1 is judged over time, the evidence that matters is the process running repeatedly, not a single clean scan on the day of the examination. A Type 2 examination asks whether the monitoring operated across the observation period, so you need recurring scan records, configuration-baseline comparisons, and tickets showing how findings were triaged and closed. A Type 1 examination focuses on whether the design is in place as of a date, but the auditor will still ask how the process would catch drift in practice. Decide early who owns the baseline, how often it is reviewed, and what counts as an approved change, because those decisions determine what evidence you can produce later.
Which systems, teams and third parties fall under CC7.1
CC7.1 only tests what sits inside the system boundary, so the scope you define in the system description decides which hosts, clusters, cloud settings and devices need vulnerability and configuration monitoring. The cards below cover the components auditors usually ask about and the scoping choices that change how much monitoring work you carry.
Production hosts and servers
Production virtual machines and bare-metal servers that run the in-scope service are the core of CC7.1. For each host, confirm that the operating system and installed packages are inventoried, that configuration is compared with a defined baseline, and that vulnerability scans cover the whole fleet, including hosts created by autoscaling. Hosts that exist outside the inventory are the most common gap an assessor finds, so check that the boundary list matches what your monitoring actually sees.
Containers and Kubernetes clusters
Container images, cluster configuration and running workloads can change faster than host-based scans can follow. Decide whether the cluster itself, its namespaces and its admission controls sit inside the boundary, and document how policy results are recorded. Policy engines that report pass or fail for existing resources give you evidence of current state, which is the form of evidence auditors expect for CC7.1 configuration monitoring.
Cloud account configuration
Cloud control planes, identity settings, storage policies, network rules and logging configuration are often the largest source of unintended exposure. Decide which accounts, subscriptions and regions are in scope, and whether shared landing-zone accounts that host in-scope services are included. Confirm that a tool records configuration drift and alerts when a security-relevant setting changes outside the approved change process.
Staff endpoints with production access
Laptops and workstations used by engineers with production access are part of the boundary when they can reach in-scope systems or hold credentials to them. Scope them by role rather than by the whole company fleet, and record which devices are covered. For each device, check that installed software is inventoried and that known vulnerabilities are matched against vendor and advisory sources, and that the device list is reconciled against the people who hold access.
Network devices and firewalls
Routers, switches, firewalls and load balancers that carry traffic to the in-scope service are often left out of software-focused monitoring. Decide whether they are inside the boundary, then confirm that their firmware versions, administrative settings and rule sets are recorded and reviewed. Where a device cannot run an agent, the evidence usually comes from configuration exports and a documented review cadence, so confirm that method with your auditor before you rely on it.
Subservice organizations carved out
A carve-out excludes a subservice organization, such as a hosting provider, from your examination, and its controls are then assessed separately through its own report. This choice reduces the systems you must monitor directly, but your system description must still state which CC7.1 activities the provider performs and how you review its reports. Confirm with your auditor whether the carve-out method or the inclusive method fits your architecture, because the answer changes which scans and configuration checks you must evidence yourself.
How the auditor tests vulnerability and configuration monitoring
The auditor starts from the organization's own words. Before testing anything, the service auditor reads the configuration standard, the vulnerability management procedure and the change-detection description, then checks whether those documents say what the systems actually do. A written baseline that no one can compare against is the first thing an assessor will question, because CC7.1 is about finding configuration drift and newly disclosed weaknesses, and that work needs a defined reference point. Points of focus in the 2017 Trust Services Criteria, including the 2022 revised points of focus, are considerations for designing and evaluating controls, not a checklist to be ticked. The auditor judges whether the design fits the organization's stated procedures, so a procedure that promises weekly scans and a tool that runs monthly will be an exception even if the tool itself works.
Next, the auditor confirms coverage. The question is whether the monitoring tools reach the full in-scope population: production servers, endpoints, cloud accounts, clusters and network devices that appear in the system description. Auditors typically compare the asset inventory against the agents, scanner targets and policy reports to find systems that exist but are not monitored, and they ask how unknown or unauthorized components are detected. Self-hosted tools such as Wazuh, Fleet, Kyverno and OpenSCAP can produce this evidence, but each one only covers what it is pointed at. Confirm scope with the auditor early, and document the reason for any system that is excluded.
For a Type 2 report, the auditor samples scan results, configuration scan outputs, policy reports and alert records across the observation period, not just one snapshot. Expect requests for a sample of scan dates, the findings that came out of each, and the tickets that show remediation or documented risk acceptance. Each exception, such as a critical finding left open past the organization's own deadline, is followed to a remediation ticket with a date, an owner and a closing action. Ask your auditor which sampling approach they will use and how many periods they expect to test, because the answer determines how much evidence your team must keep and how it should be organized.
What the assessor checks and where findings usually come from
This table sets out, for each CC7.1 area, how the assessor tests the control, the evidence they usually request, and the findings that tend to appear. Read it as a preparation checklist: the gaps in the right-hand column are the ones most often raised during fieldwork, so check them against your own environment before the auditor does.
| Area | Test approach and evidence requested | Common findings |
|---|---|---|
| Configuration standard defined and approved | Assessor reads the written baseline for each system type, confirms an owner approved it and a date, and checks that the in-scope systems were built or reviewed against it. Evidence: approved standard documents, version history, and sample build or hardening records. | Standards exist only for some platforms, approval is undated or informal, or the baseline has not been reviewed since the environment changed. |
| Monitoring covers the full in-scope inventory | Assessor compares the system description and asset inventory with the tool's enrolled or reporting population. Evidence: agent or scanner coverage reports, inventory exports, and reconciliation of missing hosts. | Hosts, containers or cloud accounts are absent from monitoring, or the inventory itself is incomplete, so coverage cannot be shown as complete. |
| Change detection alerts on configuration drift | Assessor selects changes or drift events and traces them to alerts, tickets and resolution. Evidence: file integrity or policy report samples, alert records, and the review trail showing who acted on each one. | Alerts fire but nobody reviews them, drift is detected without a documented response, or change detection is switched off for some components. |
| Unknown or unauthorized components are detected | Assessor tests whether new hosts, software or accounts are noticed and compared with the approved inventory. Evidence: discovery scan results, software inventory deltas, and records of how unrecognized items were investigated. | No defined process for unapproved assets, discovery runs only at audit time, or unauthorized items are recorded without follow-up. |
| Vulnerability scans run at the defined frequency | Assessor checks the scan schedule against the organization's own documented frequency and samples completed scan reports across the period. Evidence: scan configuration, job history, and dated scan reports covering the observation window for Type 2. | Gaps in the scan calendar, scope exclusions that were never approved, or scans that failed silently and were not rerun. |
| Findings are triaged and remediated within the organization's own timelines | Assessor selects findings and compares the recorded severity, due date and closure with the timelines the organization set itself. Evidence: triage records, risk acceptances signed by an accountable owner, and remediation tickets with closure proof. | Timelines are not defined, overdue findings are closed without evidence, or exceptions are accepted without a documented owner or review date. |
How to implement CC7.1 in sequence
This sequence turns CC7.1 from a policy statement into a working cycle: defined configuration baselines, a complete inventory, automated detection of drift and vulnerabilities, and documented decisions that an auditor can trace from finding to resolution.
Define configuration standards for each component type
Start by listing the component types in scope, such as Linux and Windows endpoints, cloud accounts, Kubernetes clusters, databases and network devices. For each type, write a configuration standard that states the approved settings, who owns it, and how it is approved. Use a recognized hardening baseline as the starting point where one exists, and record any deliberate deviations. The output is a versioned set of configuration standards with named owners and approval records, which the auditor will request first when testing the design of CC7.1.
Build the asset inventory and detect unknown components
Create an inventory of every system that handles in-scope data, drawn from cloud account listings, agent enrollment, cluster state and network discovery rather than from memory. Compare discovered assets against the inventory on a recurring basis and investigate anything unregistered. Record who reviews the comparison and how unknown components are either onboarded or removed. The output is a current asset inventory plus a log of discrepancies and their dispositions.
Deploy change detection and policy checks
Enable mechanisms that flag when a host, cluster or cloud resource drifts from its configuration standard. For endpoints, this can mean file integrity monitoring and configuration assessment. For Kubernetes, admission policies and background scans can report pass or fail results against defined rules. Confirm which events generate alerts and who receives them. The output is a policy and rule set mapped to the standards from step one, along with sample alerts or reports that show detection working.
Schedule vulnerability scans and route findings to tickets
Run vulnerability detection on the defined schedule against operating systems, installed applications and container images. Confirm that the vulnerability data source is current, either online or in a locally hosted offline copy where the environment requires it. Send each finding into the ticketing system with an owner and a severity, so that no result exists only in a scanner dashboard. The output is scan schedules, scan reports, and tickets that link back to each finding.
Set triage and remediation procedures
Write a triage procedure that defines how findings are prioritized, who decides severity, what remediation timelines the organization commits to internally, and how verification closes a ticket. Test the procedure on a sample of real findings and adjust it where teams disagree. The output is a documented triage and remediation procedure, the severity criteria used, and a set of closed tickets showing re-scan confirmation. Any internal deadlines should be set by the organization and stated in its own policy.
Document exception handling and retain the record
Where a vulnerability cannot be fixed or a configuration deviation is accepted, record a formal exception that names the risk, the compensating control, the approver and a review date. Review open exceptions on a defined cadence and close them when the underlying condition changes. The output is an exception register with approvals and review history, which shows the auditor that deviations are governed rather than ignored. Keep these records throughout the observation period if a Type 2 report is planned.
Evidence that satisfies CC7.1 and how to keep it current
An auditor testing CC7.1 looks for proof that configuration and vulnerability monitoring ran throughout the period, not only on the day of the examination. The six artifacts below connect to one another: the standards define what is monitored, the coverage and detection records show the monitoring happened, and the tickets show what was done about the findings.
Approved configuration standards
These are the baselines each system type must meet, such as hardened operating system profiles, container admission rules and cloud resource settings. Auditors check that the standards are approved by a named owner, versioned, and dated before the period starts, and that any change to them went through change management. Keep the approval record and every prior version so the auditor can see which standard applied on which date. Review them at a fixed interval and record that review.
Scanner and agent coverage reports
A coverage report shows which hosts, containers and cloud accounts run the monitoring agent or scanner, and which do not. Coverage gaps are where unmonitored configuration changes hide, so the auditor will compare the coverage list against the asset inventory. Export the report on a schedule, reconcile it with the inventory, and record every exception with an owner and a closing date. Confirm in your own environment which of your tools produce this view natively.
Change-detection alert records
Change detection flags when a monitored file, service, package or policy differs from its approved state. Keep the alert history with timestamps, the affected asset, and the disposition of each alert: approved change, reverted change or investigated event. Auditors sample these records to confirm that unauthorized drift was noticed and handled. Set retention so the full observation period is covered, and confirm the retention setting in your tool rather than relying on its default.
Unknown component reports
This report lists software, containers, accounts or network devices found on monitored systems that do not appear in the approved inventory. It addresses the CC7.1 point of focus on detecting unknown or unauthorized components. Run the discovery on a fixed cadence, route each unknown item to a named owner, and keep a record of whether it was authorized, added to the inventory or removed. A report that always shows zero unknowns is worth questioning, so confirm that discovery covers every asset class in scope.
Dated scan result exports
Vulnerability scan results prove that scanning happened, when, and against which assets. Export each scan with its date, scope, tool version and the vulnerability feed or database it used, then store the exports in an evidence repository the auditor can access. Results from a tool that only shows the latest run can erase earlier evidence, so export before the next run overwrites it. Keep the vendor or database update records alongside, since a scan against stale vulnerability data is weak evidence.
Remediation tickets linked to findings
Each significant finding should trace to a ticket that records the owner, severity, target date, fix or risk acceptance, and verification scan. Auditors follow the chain from a scan result to the ticket and then to the re-scan that confirmed closure. Link tickets to finding identifiers rather than writing them up by hand, and require a documented approval for any risk acceptance. Review open tickets past their target dates at a regular cadence and keep that review as evidence.
Self-hosted tools that produce CC7.1 evidence
For servers, workstations and virtual machines, the core CC7.1 question is whether the organization knows what software is installed and whether that software has known vulnerabilities. Wazuh and Fleet both address this, with different designs. Wazuh uses agents that collect each endpoint's software inventory and correlates it with a vulnerability repository, either the Wazuh CTI repository or a locally hosted offline copy. Fleet matches installed software on enrolled hosts against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV.
- Vulnerability findings per host: Wazuh vulnerability detection records the operating system and installed applications that match known vulnerabilities on each monitored endpoint.
- Software inventory records: Each agent's inventory shows what was installed, when it was observed and where, which lets an assessor compare the current state against prior periods.
- Source-specific matching: Fleet's results show which advisory source matched each host, so reviewers can trace a finding back to its origin.
- Offline operation: Wazuh supports a locally hosted copy of its vulnerability data, which may matter for networks that cannot reach external feeds. Confirm this for your version.
- Coverage gaps: Endpoints that never check in produce no evidence, so the inventory of enrolled hosts needs its own reconciliation.
Confirm which operating systems and application families each tool covers in your estate before relying on its findings, and keep the scan schedule and remediation tickets as the record of response.
In a Kubernetes environment, configuration is often where new exposure appears: a workload deployed without resource limits, a privileged container, or a namespace with overly broad permissions. Kyverno addresses this by enforcing policies as Kubernetes admission controls and by scanning existing resources. It writes PolicyReport and ClusterPolicyReport resources that record pass, fail, warn, skip or error results for each matching resource, drawn from both admission events and periodic background scans. Because the background scans reflect current cluster state, the reports show drift as well as new deployments.
- Admission-time results: Each create or update request that a policy evaluates leaves a result, showing whether the change was blocked, flagged or accepted.
- Background scan results: Periodic scans record the state of resources already running, which catches configuration that predates a policy.
- Per-resource detail: Each result names the resource and the policy rule it was evaluated against, which is the form most assessors expect for a sample.
- Queryable reports: Because the reports are Kubernetes resources, they can be exported and retained as evidence with the rest of the change record.
- Policy versioning: The policies themselves are configuration, so storing them in version control makes the standard that was in force auditable.
Confirm that your cluster version and admission setup support the policy types you intend to rely on, and check how long report resources are retained before they are exported.
Operating system hardening is where a defined configuration standard becomes testable. OpenSCAP runs the NIST-certified oscap scanner against SCAP content written in XCCDF and OVAL, such as profiles from the SCAP Security Guide. Each rule is reported as pass or fail, and results can be produced as HTML, ARF or XCCDF reports. This gives the organization a measurable baseline and gives the assessor a dated record of whether each host matched the standard the organization claims to enforce.
- Rule-level results: Each host's report lists every rule in the chosen profile with a pass or fail result, which maps directly to a documented configuration standard.
- Machine-readable output: ARF and XCCDF reports can be stored and compared across scan dates to show drift from the baseline.
- Human-readable output: HTML reports suit a reviewer who needs to walk through failures with the platform team.
- Profile selection as a decision: The chosen profile, and any rules deliberately excluded, should be documented and approved, since the assessor will ask why each exception exists.
- Remediation linkage: Failed rules should open tracked changes, so the scan results connect to the change management records under CC8.
Confirm that the SCAP content you use matches the operating system versions in your environment, and document how you treat rules that do not apply.
Which open-source tools support which CC7.1 evidence
This table compares four open-source tools by the CC7.1 detection they cover, the evidence each produces and the license terms to check before deployment. Read each row against your own configuration standards and asset inventory, since a tool produces evidence only for the components it is actually pointed at. The main takeaway is that vulnerability detection, configuration policy and benchmark scanning produce different records, and an assessor will expect more than one of them.
| Tool | What it detects | Evidence it produces | License caveat |
|---|---|---|---|
| Wazuh | Vulnerabilities in the operating system and installed applications of agent-monitored endpoints, matched against the Wazuh CTI repository or a locally hosted offline copy | Vulnerability detection results per endpoint from the software inventory each agent collects | GPL-2.0-only; confirm the terms apply to how you distribute or modify it |
| Fleet | Vulnerable software on enrolled hosts, matched against NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV | Per-host records of installed software and matched vulnerabilities for review and remediation tracking | MIT; confirm which data sources apply to your operating systems |
| Kyverno | Resources in a Kubernetes cluster that fail or warn against policy, from admission events and periodic background scans | PolicyReport and ClusterPolicyReport resources recording pass, fail, warn, skip or error for each resource | Apache-2.0; policy reports reflect current cluster state, so retain snapshots if you need history |
| OpenSCAP | Deviations from SCAP content such as SCAP Security Guide profiles, rule by rule, using the NIST-certified oscap scanner | Pass or fail results per rule in HTML, ARF or XCCDF reports | LGPL-2.1-or-later; confirm the profile content you use and its license |
Who owns, who prepares and who attests
Your organization owns CC7.1. The SOC 2 report describes controls you run, and the auditor tests your operation of them, so no partner can accept that accountability on your behalf. Your team decides what a secure configuration looks like for each system, which vulnerabilities are accepted, deferred or fixed, and who approves a change that moves a system away from its standard.
- Configuration standard: Approve the baseline for each operating system, container image, cloud account and application, and review it on a set schedule.
- Triage decisions: Assign an owner to each finding, record the risk decision for anything not fixed, and keep the reasoning on file.
- Remediation: Track fixes to completion and retain the tickets, change records and re-scan results that prove closure.
- Unknown components: Decide who investigates hosts or resources that appear in inventory without an owner.
Before engaging anyone, confirm that a named individual signs off on the standard and the exception process, because the auditor will ask for that person's evidence.
An implementation partner such as DeployOpen prepares the systems and evidence that your team operates. For self-hosted open-source platforms, that usually means deploying scanners and monitors inside your own cloud accounts, data centers or air-gapped network, wiring their output into your ticketing system, and writing the runbooks that tell staff what to do with a result. The partner does not decide your risk acceptances and does not issue an opinion on your controls.
- Deployment: Install and configure tools such as Wazuh, Fleet, Kyverno and OpenSCAP inside your environment.
- Evidence exports: Build scheduled reports and retention so that scan results and policy reports can be pulled for any audit period.
- Runbooks: Document the triage workflow, escalation paths and re-scan steps.
- Scoped security testing: Test whether scanning actually detects the weaknesses it claims to, under a written scope.
Auditor independence limits this role. Where the same firm would design controls and then test them, the auditor may be unable to rely on the work, so ask your CPA firm in advance which preparation tasks it accepts from a third party. Get the division of work in the written scope.
The independent CPA firm is the only party that tests CC7.1 and issues the SOC 2 report. It examines whether your configuration monitoring is designed to meet the criterion, and for a Type 2 report, whether it operated effectively across the observation period. It does this under AT-C section 205 of the AICPA attestation standards, which also requires written representations from management.
- Design testing: Confirm that standards, change detection and scanning are described and capable of finding the risks in scope.
- Operating testing: Sample scan cycles, findings and tickets across the period and check the timing and completeness of each step.
- Exceptions: Report any gap as an exception, which you can explain in the report.
- Representations: Management signs a representation letter confirming the controls and the description are accurate.
The firm does not configure your tools or write your standards for you, and it should not be the company that prepares the evidence it later tests. Ask the firm to set out its independence rules in its engagement letter.
Several CC7.1 tasks are routinely outsourced, while others stay in-house regardless of who does the work. The split depends on how much of the monitoring stack you run and how much internal capacity you have, so write it down before the observation period starts.
- Usually outsourced: Tool deployment, scanner tuning, evidence export automation and periodic configuration testing.
- Usually kept in-house: Configuration standard approval, risk acceptance, final remediation sign-off and incident-driven decisions.
- Shared: Runbook writing, where the partner drafts and your team approves and operates.
- Ongoing costs: Tool hosting, licensing where it applies, and staff time for triage recur each year, while deployment is largely one-time.
- Quote requests: Ask for a written scope listing each task, the owner, the deliverable and the handover date.
Confirm the split with your auditor before work begins so that no required evidence depends on a party the auditor cannot rely on.
Where CC7.1 programs usually fall short
CC7.1 programs rarely fail on tooling. They fail on scope, ownership and follow-through: the scanner never saw the workloads, the findings sat untriaged, or the evidence was assembled in a rush. The six gaps below are the ones assessors most often find when they test whether monitoring actually detects configuration drift and new vulnerabilities.
Inventory misses cloud and container resources
Scanners and agents often cover the virtual machines that were present when the tool was installed, but not short-lived containers, serverless functions or new cloud accounts. An assessor will compare the asset list against the cloud console and the cluster state. The fix is to drive the inventory from the platform itself, reconciling the agent or host list against cloud and cluster inventories each review cycle, and documenting which asset classes are in scope.
Scans run but findings go untriaged
A vulnerability scan that produces a report nobody reviews does not show that monitoring works. Assessors look for a record of each finding, its severity, an owner and a disposition such as fix, accept or false positive. The fix is a documented triage queue with named owners and a rule for which findings open tickets automatically, so the scan history links to real remediation work.
Configuration standards live only on a wiki
When hardening baselines exist as a wiki page, nothing checks systems against them, and the page drifts from what is deployed. CC7.1 expects defined configuration standards that monitoring can measure. The fix is to express the baseline as machine-readable policy, such as SCAP content evaluated with OpenSCAP or admission policies enforced with Kyverno, and to keep the policy files under version control with the wiki pointing to them.
Change detection with no named owner
Drift alerts fire, but no one is accountable for deciding whether an unexpected change was authorized. Assessors ask who receives configuration change alerts, how quickly they are reviewed, and how an unauthorized change is escalated. The fix is to assign each alert class to a role, define a review window, and record the decision on each alert so that detection and response are traceable to a person.
Exceptions without expiry
A deferred patch or an accepted misconfiguration often stays open indefinitely because nothing forces a second look. Exceptions with no owner, reason or end date quietly become permanent gaps in the monitored environment. The fix is an exception register where each entry records the risk accepted, the compensating control, the approver and a review date, with overdue entries reported to management before the next scan cycle.
Evidence gathered only at audit time
Teams that rebuild scan results, policy reports and triage records just before fieldwork cannot show that monitoring operated across the audit period, which a Type 2 examination tests. The fix is to export scan results, policy reports and exception records on a fixed schedule into retained storage, so the auditor can sample across the period. Confirm retention settings and export formats with each tool's documentation before relying on them.
CC7.1 questions buyers and practitioners ask
How much effort does CC7.1 take to run in-house?
Expect CC7.1 to be an ongoing operating task rather than a one-time project. The effort depends on how many systems are in scope, how many distinct configuration baselines you maintain, how often your environment changes, and how many people review scan results and decide what to fix. Each of these drivers grows with the environment. Teams with a stable, well-documented estate and a single owner for configuration standards usually carry a lighter load than teams running multiple cloud accounts, Kubernetes clusters and mixed operating systems. Before committing headcount, map every system type in scope, list who approves a baseline change, and ask your CPA firm which monitoring evidence it expects to sample across the observation period.
Do open-source tools remove the cost of CC7.1?
Open-source tools remove license fees for the scanners themselves, but they do not remove the work of running them. Your organization still pays for the staff who define configuration standards, deploy agents, tune policies, triage findings, document exceptions and retain results. Hosting, storage and any paid support contract are additional costs. Tools such as Wazuh, Fleet, Kyverno and OpenSCAP each cover a different part of the control, so the real question is whether the combined set covers your asset types without gaps. Ask any implementation partner to itemize setup, integration and ongoing operating costs separately in a written scope, and confirm license terms for each component with its vendor before you rely on them.
How long must CC7.1 evidence be retained for a Type 2 report?
Retain CC7.1 evidence for the full observation period of the Type 2 report, plus enough history for the auditor to sample from any point within it. The observation period is set by the engagement, and the auditor decides which records it samples, so agree the retention window with your CPA firm at the start. Keep scan outputs, baseline definitions, change-detection alerts, exception approvals and the tickets that show remediation. Store them in a location that prevents silent alteration and can be retrieved by date. Your own retention policy should match the period the auditor needs, and you should confirm the exact requirement with the auditor rather than assume a number.
Can a partner run the vulnerability scans for us?
Yes, an implementation partner can deploy, configure and operate scanning tooling inside your infrastructure, but the control remains yours. Management owns the configuration standards, the decision to accept or remediate a finding and the evidence that the process ran. The partner prepares the systems, documents the procedures and produces the records. Under a fixed-scope engagement, the written scope should name which scans the partner runs, how often, who receives the output, who triages it and who signs off on exceptions. DeployOpen implements, hardens and documents self-hosted open-source platforms inside client environments and can run security testing, but it does not issue audit reports, so the auditor's independent testing still applies.
What must our team supply to make CC7.1 work?
Your team must supply the decisions and access that only your organization can give. That includes an inventory of systems and cloud accounts, named owners for each configuration baseline, access to the environments where agents and admission controllers will run, and an approver for exceptions and risk acceptance. Your team also needs a ticketing or workflow process where scan findings are assigned and closed. Ask your partner for a list of inputs before work starts, and confirm which items must come from security, platform engineering, application owners and finance. Missing owners and unclear approvers are the most common reasons evidence becomes weak during fieldwork.
Can the auditor help design the CC7.1 controls?
An independent CPA firm can explain what the criterion expects and what evidence it will test, but it should not design your controls. Designing controls and then auditing them creates an independence conflict. A common arrangement is for the auditor to review your control matrix and walk through the evidence it will sample, while a consultant or implementation partner helps build the procedures. Ask your audit firm in writing what it can and cannot do before work starts, and check the engagement letter for any language about advisory services. Treat the auditor's feedback as a test of whether your design is testable, not as sign-off on its quality.
How does CC7.1 relate to CC7.2 monitoring?
CC7.1 focuses on finding configuration changes that introduce vulnerabilities and exposure to newly disclosed vulnerabilities, while CC7.2 focuses on monitoring system components for anomalies that could point to malicious acts, disasters or errors. The two share tooling and data, since a change detection alert can also be a monitoring signal, but they answer different questions. CC7.1 asks whether your known configurations and software inventory stay within your standards and whether scans find known weaknesses. CC7.2 asks whether unusual activity is noticed and analyzed. Map each tool to the criterion it supports so that the auditor can see which evidence serves which control and where the boundary between them sits.
How DeployOpen prepares CC7.1 evidence
DeployOpen is a Chainscore Labs company that plans, implements, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For CC7.1, that means the monitoring stack described above is deployed and configured in your environment, the configuration standards it checks against are written down, and the vulnerability scanning and change detection produce records an auditor can sample. DeployOpen prepares the systems and evidence; it does not issue SOC 2 reports, opinions or attestations. Only the independent CPA firm performing your examination can do that, and your organization owns the controls and the decisions about what counts as an acceptable configuration or an acceptable remediation window.
Engagements are fixed-scope. Before work starts, we agree in writing which platforms are in scope, which hosts and clusters are covered, which scanners and policy engines are deployed, how their outputs are retained, and which deliverables you receive, such as the configuration baselines, scanner and policy configuration, runbooks for triaging findings, and an evidence map that ties each output to the CC7.1 points of focus. Ask any implementation partner to confirm in the quote who approves baselines, who receives alerts, and where exported reports are stored, because an auditor will ask who performed each step.
Because CC7.1 is tested over a period in a Type 2 examination, the controls must keep running after the initial build. Scoped security testing can check whether scanners actually detect the vulnerabilities and configuration drift you expect, and retainers can cover ongoing upgrades, scanner data currency and reviews of exceptions between audit periods. Ask your auditor which evidence formats and sampling periods they will accept before deciding what to outsource, and ask any partner to state in writing which tasks remain with your own security and operations staff.
