CC6.8 malicious and unauthorized software: what the criterion asks for and why it is hard
CC6.8 asks the organization to implement controls that either prevent unauthorized or malicious software from being introduced, or detect it and act on it. If an auditor or customer asks how software installation and malware are controlled, the answer should name both halves: what stops unapproved software from getting onto systems, and what notices when something gets through anyway. The organization owns these controls. A CPA firm tests them and issues the report, and an implementation partner can help build and document the evidence. The prevention half covers restricting who can install or modify software, a defined change control process for software and configuration, and anti-malware protection on endpoints and servers. The detection half covers monitoring for unauthorized changes to software and configuration parameters, and scanning information assets that come from outside the organization, such as laptops returning from travel, removable media, vendor appliances and files uploaded into the environment. Under the points of focus, these are characteristics to consider in designing the control, not a checklist that every item must satisfy. Confirm with your auditor which points of focus they will expect to see addressed in your environment.
The difficulty is coverage and proof. Software lives on laptops, servers, containers, build pipelines and third-party appliances, and each has a different owner and tooling, so a control that works on the corporate fleet may silently miss a staging cluster. For a Type 2 report, the auditor also needs evidence that the control operated across the whole observation period, not only on the day of testing. That means logs, scan reports, alert records and exception tickets must be retained and traceable to specific systems and dates. An illustrative example: a team that enables file integrity monitoring on production servers in month three, but not on the build runners until month nine, will struggle to explain a six-month gap. Map every asset class to a named control owner before fieldwork begins.
Which systems, teams and third parties CC6.8 covers in your SOC 2
CC6.8 applies wherever software can be installed, changed or introduced into your environment, so the scoping question is where that happens. The cards below cover the decisions that most often change the size of the control work, and what to confirm with your auditor before fieldwork starts.
Production servers and cloud workloads
Production hosts, container nodes and cloud workloads are the core of CC6.8 because unauthorized software there reaches customers directly. Scope every production image, runtime and administrative host, not only the application tier. Confirm with the auditor whether the cloud provider's infrastructure is carved out as a subservice organization, and which parts of software control remain with you, such as your base images, agents and configuration baselines. Expect file integrity monitoring and process inventory to be evidenced here, for example with Wazuh file integrity monitoring or scheduled osquery queries.
Employee laptops and mobile devices
Staff endpoints are the most common route for unapproved software, browser extensions and malware into a service organization. Confirm with the auditor whether personal devices used for email or code are in the system boundary, and whether they must be managed or only covered by policy. Your evidence will usually show the installation restriction, the anti-malware status of each device, and the exceptions process for software requests. Endpoint inventories should be sampled as part of the population the auditor selects.
CI/CD pipelines and build artifacts
Build servers, runners and artifact registries can introduce malicious code without any change to production hosts, so they belong in CC6.8 scope even when they are also covered by CC8 change management. Confirm with the auditor who may modify pipeline definitions, how build dependencies are pinned and verified, and whether signed artifacts are checked before deployment. Evidence commonly includes pipeline access logs, approval records and integrity checks on the built output.
Files imported from outside the organization
Vendor packages, container base images, third-party libraries and customer-uploaded files all arrive from outside the entity, and the points of focus for CC6.8 expressly include scanning information assets from outside the organization. Confirm with the auditor which intake points are in scope, what scanning is performed before import, and how scan results are recorded and acted on. Document the rule for what happens when a scan fails, because the auditor will test that path as well as the scanner.
Build and administrative teams
Engineers and administrators who can install, modify or push software hold the privileges that CC6.8 most needs to constrain. Confirm with the auditor which roles can change software and configuration in production and build systems, and how those roles are reviewed. The control depends on the same access records used for CC6.3, so agree early which population the auditor will sample and how privileged installation is approved and logged.
Subservice organizations and carved-out controls
Hosting providers, managed endpoint services and third-party scanners may perform part of the CC6.8 control, and you may carve their controls out of your report. Confirm with the auditor which subservice organizations are relevant, whether their SOC reports cover malware protection and change detection, and which complementary controls remain your responsibility. Make sure the carve-out is documented in the system description, because gaps there tend to surface late in fieldwork.
How an assessor tests CC6.8 and what they ask to see
This table sets out, row by row, how an assessor typically tests the controls behind CC6.8, what they ask the organization to produce, and where examinations most often raise questions. Read it as a preparation checklist: each row names the evidence to have ready before fieldwork, and the findings column shows where operating records tend to be thin. The main takeaway is that a Type 2 examination tests whether the controls ran consistently across the period, not only whether a tool was installed.
| Test area | Evidence requested | Common findings |
|---|---|---|
| Restriction of software installation and modification | Endpoint and server configuration standards, software allowlist or approved-software list, privilege settings showing who can install software, and sample tickets for approved installs | Local administrator rights granted broadly, no approved-software list, or installs that cannot be traced to an approval |
| Detection of unauthorized changes to software and configuration | File integrity monitoring configuration, baseline definitions, sample alerts with their disposition, and records showing how alerts were reviewed and closed | Monitored paths do not cover critical binaries or configuration files, alerts are generated but not reviewed, or baselines are never refreshed after approved changes |
| Defined change control process | Written change procedure, change tickets linking requested change, approval, testing and deployment, and records matching detected changes to approved changes | Detected changes with no matching ticket, emergency changes without after-the-fact review, or approvals given by the person who made the change |
| Anti-malware coverage | Asset inventory reconciled against agent deployment reports, policy settings, signature or detection update records, and detection and response tickets | Assets missing from the anti-malware console, disabled agents on servers, or detections recorded without documented follow-up |
| Scanning of assets from outside the organization | Procedure for screening media, devices and software packages before they join the environment, scan logs with dates and assets, and exception approvals | Contractor laptops or removable media connected without a scan record, or scans that run but results are never reviewed |
| Type 2 operating period sampling | Population lists for the period (installs, alerts, changes, new assets), sample selections made by the auditor, and the supporting record for each selected item | Gaps in evidence for part of the period, populations that do not reconcile to system records, or controls that were configured but not run regularly |
How to implement CC6.8 in the order an auditor will check it
This sequence builds the controls that prevent unauthorized software, detect changes to it, and show an auditor a working response path before the observation period starts. Each step produces an artifact the auditor can sample during a Type 2 examination.
Define the software baseline and install approvers
Management writes down which software, operating system images, browser extensions and configuration parameters are approved for each asset class, and names the people who may approve a new install or change. Engineering leads and the security owner sign the list, and the approver roster is tied to the change control policy. Done means every production host and endpoint group has a referenced baseline and a named approver, and the auditor can trace a sampled install back to an approval.
Restrict installation rights on endpoints and servers
IT administrators remove local administrator rights from standard users, lock down package installation on servers, and limit who holds privileged accounts that can change system software. Access to software repositories and application allow-lists is configured so that only approved packages can be deployed. Done means a test standard user cannot install unapproved software, and the configuration export and the list of privileged holders are saved as evidence.
Set up anti-malware and intake scanning
The team deploys anti-malware or endpoint protection on every in-scope asset, configures signature or behavior updates, and sets up scanning for files and packages that enter from outside the organization, such as email attachments, downloaded installers, removable media and third-party artifacts. The team confirms which tool and which scan policy cover each asset class. Done means a coverage report shows every in-scope asset reporting, and a test file from a known-bad sample is quarantined and logged.
Establish file integrity and configuration baselines
Wazuh file integrity monitoring or an equivalent tool records a baseline of checksums and attributes for system binaries, configuration files and security-relevant directories. The team decides whether checks run on a schedule or in real time, and records which paths are monitored and why. Where a backup product offers Verify jobs, such as Bareos, the team evaluates whether those comparisons add coverage. Done means a baseline snapshot exists for each monitored host, and a deliberate test change produces an alert with the user or process and the time.
Schedule fleet-wide queries for unexpected processes and modules
Security engineering deploys osquery across the fleet and schedules queries for running processes, loaded kernel modules, open network connections, browser plugins and file hashes. Results are sent to a central store, and the team defines which results count as unexpected by comparison with the baseline from the earlier step. Velociraptor hunts can be used for ad hoc collection across a group of systems. Done means the scheduled queries return from every in-scope host, and a documented exception list shows the expected entries.
Connect alerts to the change control process
Each alert from file integrity monitoring and fleet queries is routed to a ticket or case record. The team matches the alert to an approved change ticket where one exists, and flags anything without an approved change for review. Done means a sampled alert can be traced to either an approved change record or an open investigation, and the mapping between alert sources and the change system is documented.
Write the investigation and response procedure
The security owner writes a procedure that states who triages an alert, how the team decides whether software is unauthorized or malicious, when to isolate the asset, how removal is recorded, and when incident response is triggered. The procedure names roles, not individuals, and is approved by management. Done means at least one tabletop walk-through is recorded, and the closed case files show the procedure was followed.
Test the full chain before the observation period starts
The team runs a controlled test: install an unapproved test package on a sample host, confirm that the restriction or anti-malware control blocks or detects it, confirm the integrity monitor and fleet query record the change, and confirm the alert reaches a case with the investigation steps completed. The test is written up with dates, outcomes and any gaps fixed. Done means the test record is complete and the team knows which evidence the auditor will request. Confirm with your auditor how many test cycles they expect before fieldwork.
Which self-hosted open-source tools can produce CC6.8 evidence
CC6.8 asks whether unauthorized or malicious software is prevented, or detected and acted on. The four tools below cover different parts of that question: fleet-wide host queries, forensic collection, file integrity monitoring and backup-catalog verification. None of them is an anti-malware product, so each should be paired with a defined control for prevention where one is needed.
osquery for fleet-wide host queries
osquery exposes running processes, loaded kernel modules, open network connections, browser plugins, hardware events and file hashes as SQL tables. Its osqueryd daemon can run those queries on a schedule across an entire fleet of hosts, so unexpected software, unknown kernel modules or unusual browser extensions can show up in recorded results. Before relying on it, confirm that the query set, schedule and result retention match the software inventory and monitoring your CC6.8 narrative describes. License: Apache-2.0 OR GPL-2.0-only. Confirm fit for your environment and license obligations.
Velociraptor for targeted hunts
Velociraptor collects forensic artifacts defined in VQL from endpoints. Its hunts collect one or more artifacts across a group of systems, schedule machines that are offline to collect when they reconnect, and create a notebook per hunt for analyzing the combined results. This suits investigating a suspected unauthorized binary or software installation across many machines and keeping the record of what was found. Confirm that your endpoints can reach the server and that hunt records meet your evidence retention rules. License: AGPL-3.0-only. Confirm fit for your environment and license obligations.
Wazuh for file integrity monitoring
Wazuh file integrity monitoring records a baseline of checksums and attributes for monitored files and directories. It then raises an alert when a user or process creates, modifies or deletes a monitored file, either on a schedule or in real time, and records how and when the change happened and who made it. For CC6.8, this addresses detection of unauthorized changes to system binaries and configuration. Confirm which paths are monitored, who receives alerts and how alerts are acted on. License: GPL-2.0-only. Confirm fit for your environment and license obligations.
Bareos for backup verification
Bareos Verify jobs compare files against previously cataloged attributes, which gives a Tripwire-like capability for detecting changes after a break-in. This can show that protected files on a backed-up system no longer match the catalog, which is useful as a second check beside real-time monitoring. Confirm which systems are included, how often Verify jobs run and who reviews mismatches, since a Verify job only detects differences it is configured to compare. License: AGPL-3.0-only. Confirm fit for your environment and license obligations.
What evidence passes CC6.8 and how to keep it current between audits
Prevention evidence shows that the organization stopped unauthorized or malicious software from being installed or introduced in the first place, or screened it before use. An assessor will look for records that name the control, the asset or population it covers, the date it ran, and the person or system responsible. A screenshot of a policy does not do this on its own. The records that usually carry the weight are installation restriction settings, the approved software list with its approval dates, anti-malware coverage reports showing which endpoints were enrolled and reporting, and logs from intake scanning of files or packages that arrive from outside the organization.
- Installation restriction settings: Export the current configuration of the allow or deny rules with a timestamp, and keep prior exports so changes are visible across the period.
- Approved software list: Keep a versioned list with an owner, the date each entry was approved, and the reason for any removal.
- Anti-malware coverage reports: Record monthly counts of enrolled assets against the asset inventory, with the unenrolled exceptions listed by name.
- Intake scan logs: Retain the scanner output for each file or package brought in from outside, linked to the requester and the approval.
- Exception approvals: Date and sign each exception to an installation rule, and set a review date.
Confirm with your auditor which populations they expect you to cover and how they want exceptions presented.
Detection evidence shows that the organization noticed unauthorized or malicious software or unauthorized changes to software and configuration, and acted on what it found. The strongest records are time-stamped alerts with enough detail to show what changed, when, and which user or process made the change, followed by a documented response. Baselines matter as much as alerts, because a change can only be detected against a known state. Recurring query results and verification reports also serve as proof that the detection ran on schedule, not only when someone remembered to run it.
- File integrity alerts: Keep alert records for monitored system and application files, including the creation, modification or deletion, the actor, and the disposition.
- Fleet query results: Save scheduled query outputs for process, kernel module, network connection and browser extension checks, with the run date and host population.
- Baseline snapshots: Store the checksum and attribute baseline for each monitored set at the time it was approved, and record each re-baselining as its own event.
- Verify job reports: Retain backup verification reports that compare current files against cataloged attributes, with the job identifier and date.
- Response tickets: Link every investigated alert to a ticket showing the triage decision and the outcome.
Check that the alert pipeline is retained for the full observation period, since logs that roll off early leave gaps an assessor will ask about.
Change control evidence connects what the organization intended to change with what actually changed. An assessor will usually start from a detected modification or a deployment and trace it back to an approved request. This works only if the change record is created before the change, not reconstructed afterward. Each record should show the requester, the reviewer, the approver, the implementation date, and the test result, and each detected unauthorized change should be matched against this set. Unmatched changes are the findings that matter most, so the matching exercise is itself evidence worth keeping.
- Approved change tickets: Keep tickets that record scope, rollback steps, and approval before implementation, with timestamps from the tracking system.
- Linked detections: Tie each file integrity or configuration alert to the change ticket it corresponds to, or to an incident record if no ticket exists.
- Review records: Retain peer review or code review approvals for changes to software and configuration, showing the reviewer is not the author.
- Exception approvals: Record emergency or out-of-process changes with a retrospective approval date and the reason it could not wait.
- Monthly reconciliation: Run a monthly comparison of detected changes against approved tickets and file the result with any open items.
Before the audit, ask your auditor how they want unmatched changes presented and confirm the reconciliation is signed by a named owner.
What meeting CC6.8 costs in money and effort
This table compares each cost component of meeting CC6.8, who is paid for it, whether it is one-time or recurring, what drives it up and how to keep it down. No prices or durations are given because none are published here, so use the list to structure a written quote. The main takeaway is that open-source tooling mainly removes license spend, while staffing for tuning, triage and evidence remains.
| Cost component | One-time or recurring | What drives it | How to keep it down |
|---|---|---|---|
| Endpoint protection or anti-malware licenses | Recurring | Number of endpoints and servers, vendor licensing model, and whether a commercial agent is chosen over open-source monitoring | Confirm which assets need a licensed agent, and compare per-endpoint and per-server pricing in writing |
| Engineering time to deploy and tune monitoring | One-time, with recurring tuning | Number of platforms, fleet size, and how many query packs or file integrity policies must be written for each host type | Start with a narrow set of critical hosts, then extend coverage in stages after the first tuning cycle |
| Baseline and allowlist maintenance | Recurring | Frequency of approved software and configuration changes, and how many images or builds are in use | Tie baseline updates to the change control process so approvals and baseline changes happen together |
| Alert triage and change review time | Recurring | Alert volume from file integrity monitoring and process queries, and the number of staff who can judge an alert | Reduce noise through tuned rules and exclusions that are documented and reviewed, and define who owns each alert type |
| External penetration or configuration review, if chosen | Recurring or per engagement | Scope of hosts tested, depth of configuration review, and whether testing covers malware controls or only exposed services | Keep the scope written and limited to the controls being evidenced, and ask for the methodology before signing |
| Auditor testing effort | Recurring each examination period | Number of in-scope systems, sampling approach, whether the auditor needs screenshots or exports, and how well evidence is organized | Agree the population and evidence format with the auditor before fieldwork, and keep reports from the monitoring tools retrievable |
| Staff time to maintain the open-source stack | Recurring | Upgrades, certificate and agent maintenance, and the number of people trained to run the platform | Assign a named owner, document runbooks, and use a support retainer only for scope that internal staff cannot cover |
Who owns CC6.8, what a partner can prepare and what the auditor will not do
Your organization owns CC6.8. The controls that prevent or detect unauthorized software exist only if people in your company approve what is installed, decide what the security tools alert on, and act when something looks wrong. A partner can build the tooling, but the policy decisions, the approvals and the response remain with your staff, and the auditor will ask who performed each step and who reviewed it.
- Software approval: Named owners decide which software, browser extensions and configuration changes are allowed, and they record those decisions in a list the auditor can sample.
- Alert triage: Someone in your security or operations team reviews file integrity and endpoint alerts on a defined schedule and documents the disposition of each one.
- Anti-malware policy: Your team sets the policy for endpoint protection, exclusions and update cadence, and confirms that agents remain installed on in-scope assets.
- Incident handling: When a detection indicates unauthorized software, your staff contain the host, investigate and record the outcome through the incident process.
- Change control: Your change process determines which modifications to software and configuration are authorized before they happen.
Before the audit period begins, confirm that each of these responsibilities has a named owner and a recurring record, because gaps here are the most common reason an operating effectiveness test produces exceptions.
An implementation partner such as DeployOpen plans, deploys and tunes the open-source tools that support CC6.8 inside your own cloud accounts, data centers or air-gapped networks. The partner prepares systems and evidence. It does not decide your policy, does not approve software on your behalf, and does not attest to whether the control operated, because that would compromise the independence the examination depends on.
- Tool deployment: The partner installs and configures tools such as osquery, Velociraptor and Wazuh so that they cover the asset inventory your team defined.
- Baseline and tuning: The partner builds file integrity baselines and query packs, then tunes them so alerts reflect the environment rather than noise.
- Procedure documentation: The partner writes runbooks that describe how the tools are operated, who receives alerts and how exports are produced.
- Evidence preparation: The partner configures scheduled exports and retention so that the auditor can request records for the full observation period.
- Hardening and upgrades: The partner maintains the tooling and documents version changes, which feed into the change management evidence.
In a fixed-scope engagement, ask the partner to list every artifact it will hand over, who owns each one after handover, and which items remain your responsibility.
Only an independent CPA firm can examine your controls and issue a SOC 2 report. The auditor tests whether the CC6.8 controls are designed suitably and, in a Type 2 examination, whether they operated effectively across the observation period. A SOC 2 is an assertion-based examination under AT-C section 205, so the auditor also obtains written representations from management. Neither a partner nor a consultant can sign that opinion.
- Design testing: The auditor reviews whether the controls, as described in the system description, would address the risk of unauthorized or malicious software.
- Operating effectiveness testing: The auditor samples alerts, approvals, scans and change records across the period and checks that they were performed as described.
- Evidence independence: The auditor may request raw data directly from the tools, so exports prepared by a partner should be reproducible from the source system.
- Exceptions: Any deviation is reported as an exception in the report, and the auditor does not adjust findings to suit the client.
- Report issuance: Only the CPA firm issues the report, and it is shared under the terms the report itself allows.
Before engaging anyone, confirm with your CPA firm which evidence it will sample, in what format, and how it will treat artifacts that a partner generated.
Where CC6.8 programs usually fall short and how to close each gap
Most CC6.8 failures are not missing tools. They are unowned approval lists, agents that stopped reporting, alerts nobody reviews and evidence that disappears partway through the observation period. The cards below pair each gap with a fix you can check before the auditor does.
No owner for the software approval list
An allowlist of approved software exists on paper, but nobody is accountable for updating it, so new installs and removals drift from it. Name a single owner, record each addition with a business reason and approver, and review the list on a set schedule. Ask whether the owner can show the approval for any package currently installed on a sample of endpoints, and whether that approval predates the install.
Anti-malware deployed but not reporting
An endpoint protection agent that is installed but silent looks the same on a dashboard as one that is healthy until you check the last check-in time. Pull a current list of assets with no recent agent heartbeat, confirm signature or definition updates are applied, and treat any gap as a finding to investigate. Keep the console export that shows coverage across the full period, not only the day of the audit.
File integrity monitoring turned on without reviewed alerts
Wazuh file integrity monitoring can alert when a user or process creates, modifies or deletes a monitored file, but alerts that are generated and never triaged give no assurance. Define which paths are monitored, assign a reviewer, and record the disposition of each alert as expected change, approved change or incident. Confirm that the reviewer's dispositions are retained, since the auditor will sample them.
Alerts that never reach change control
A detected unauthorized change only supports CC6.8 if it leads to action. Route integrity and endpoint alerts into the same ticketing workflow used for change management, so each unexpected change is either linked to an approved change record or opened as an incident. Check a few alerts from the period and trace each one to its ticket, approval or closure note.
External packages and containers scanned inconsistently
Software pulled from outside the organization, such as open-source libraries, base container images and vendor installers, is a common path for malicious code. Scan these artifacts at the point of entry into your registry or build pipeline, not only in production, and define what blocks a release. Ask whether scanning covers every image and package source in use, and whether exceptions are approved and dated.
Tools configured but evidence not kept for the full period
A Type 2 examination tests whether controls operated across the whole observation period, so a tool that was configured in month one but whose logs were rotated away fails to show that. Set retention for scan results, agent coverage exports, FIM alerts and approval records before the period starts, and store them outside the systems they describe. Ask the auditor which populations and time ranges they plan to sample.
Questions buyers ask about CC6.8 cost, effort and outsourcing
How much effort does CC6.8 take and what drives it?
CC6.8 effort is driven mainly by how many systems you run, how often software and configuration change, and how much of the control set already exists. The criterion asks for controls that prevent, or detect and act on, unauthorized or malicious software, so the work covers software installation restrictions, change detection, anti-malware coverage and scanning of assets that arrive from outside the organization. A small fleet with a clear change process and managed endpoints needs far less work than a mixed fleet of servers, laptops and containers with ad hoc installs. The largest single driver is usually the number of distinct asset types that must be covered and proven. Ask a partner to break the effort into those asset types in the written scope.
Can our team meet CC6.8 without outside help?
Yes, many teams meet CC6.8 with internal staff, provided someone owns the controls and can produce evidence on request. The work is mostly configuration, monitoring and record keeping rather than novel engineering. Outside help is most useful when nobody has time to deploy the tooling, when the control design needs a second opinion, or when the team lacks experience with file integrity monitoring and endpoint telemetry. The organization always owns its controls. An implementation partner can prepare systems and evidence, but only an independent CPA firm issues the SOC 2 report.
How long do deployment and evidence collection take?
Deployment and evidence collection usually take longer than the tool installation itself, because the evidence has to show that the controls ran consistently over the examination period. Installing an agent or enabling a monitor is quick compared with defining baselines, tuning alerts, writing the change control steps and getting reviewers to act on findings. For a Type 2 examination, the auditor will expect a history of alerts, reviews and approvals, so collection should start early. Confirm the expected duration in the written scope rather than relying on a general estimate.
Does open source remove the need for paid tools?
Open source removes most software license fees for the detection tooling, but it does not remove the work of running it. Tools such as osquery, Velociraptor, Wazuh and Bareos can cover inventory queries, forensic collection, file integrity monitoring and verification jobs. You still pay for the infrastructure that hosts them, the staff time to configure and maintain them, and any commercial support you choose to buy. Some organizations also keep a paid endpoint protection product for anti-malware, so confirm which capabilities each tool covers in your environment before deciding what to replace.
What does the work need from engineering and security staff?
Engineering staff need to deploy agents, define which software and configuration paths are monitored, and integrate change records with deployments. Security staff need to define the approved software list, set alert thresholds, review findings and document how unauthorized changes are investigated. In practice this means a named owner for each control, time for alert triage, and access to the systems being monitored. Ask the partner to name which roles each deliverable requires so you can plan the hours before the engagement starts.
Can the auditor also set up the CC6.8 controls for us?
Generally no. The CPA firm performing the SOC 2 examination must stay independent of the controls it tests, so it should not design, deploy or operate them for you. An auditor can explain what evidence it expects, but building the controls is a separate engagement. Keeping these roles apart protects the credibility of the report. Ask any firm to confirm in writing what it will and will not do before you sign its engagement letter.
What should we ask a partner for in a written, fixed-scope quote?
Ask for the written scope, the list of systems and asset types covered, and the deliverables for each. The quote should state which tools are installed, which configurations and baselines are created, what runbooks and change control steps are documented, and what evidence exports are produced. It should also name your responsibilities, such as access to systems and staff time, and what happens if the scope changes. Fixed-scope quotes are agreed in writing before work starts, so ask for a timeline tied to those deliverables rather than an open-ended estimate.
How DeployOpen scopes, implements and prepares CC6.8 evidence
DeployOpen is a Chainscore Labs company that plans, implements and hardens self-hosted open-source platforms inside the client's own infrastructure. For CC6.8, we prepare the software control, monitoring and change-detection systems and the evidence they produce, while the organization owns its controls and an independent CPA firm alone issues the SOC 2 report.
How we scope
- Agree in writing which endpoints, servers and cloud workloads fall inside the CC6.8 boundary before work starts.
- Document which software installation, modification and configuration changes the organization restricts, and who approves exceptions.
- Confirm with the CPA firm which CC6.8 points of focus the controls will address and which evidence the auditor expects.
How we build
- Deploy osquery to run scheduled queries on running processes, kernel modules, browser plugins and file hashes across the fleet.
- Configure Wazuh file integrity monitoring with baselines for critical binaries, configuration files and system directories, with alerting enabled.
- Connect anti-malware and inbound file scanning so software arriving from outside the organization is checked before it reaches production.
How we hand over
- Deliver a control description and runbook covering who reviews alerts, how unauthorized changes are triaged and how change control links to them.
- Provide configuration as code and sample query and alert outputs so the auditor can test the controls over the observation period.
- Document the tested controls, owners and evidence locations in a handover pack that the organization keeps and maintains.
How we support
- Support is available as a retainer for tuning detections, applying upgrades and keeping baselines current through the audit period.
- Continuous testing of the monitoring stack can be added to the retainer if the organization wants periodic assurance between audits.
- Any change to scope, platforms or deliverables is recorded in a written change to the fixed-scope agreement before it takes effect.
