What CC5.2 technology general controls require in a SOC 2
CC5.2 asks you to show that the technology your business processes depend on is governed by control activities of its own. If your SOC 2 is due and the auditor has asked how technology controls support business processes, the answer is a documented set of general controls over the systems, tools and change paths that automated processes run on. This criterion restates COSO Principle 11 in the 2017 Trust Services Criteria: the organization selects and develops general control activities over technology to support the achievement of its objectives. The auditor is not looking for a single tool. They are looking for a reasoned link between each business process that relies on software and the technology controls that keep that software reliable, secure and correctly changed.
The reason this matters is dependency. A payment approval workflow, a customer data export or a billing run may contain controls written inside the application, but those controls only hold if the underlying infrastructure, access paths and release process also hold. The points of focus under CC5.2 organize this around three areas: control activities over technology infrastructure, security management processes, and technology acquisition, development and maintenance. In practice, the first step is to list the automated processes in scope, then trace each one down to the hosts, identity provider, logging pipeline, deployment pipeline and vendor components it uses. Confirm with your auditor how far down that chain they expect you to document, because the expected depth shapes the rest of the work.
The difficulty is that these controls rarely sit in one place. Cloud accounts, configuration baselines, endpoint agents, ticketing tools, code repositories and staff with privileged access are often owned by different teams and recorded in different systems. A control may exist on paper while its evidence lives in a tool nobody has been asked to export. The practical starting point is an inventory that names each technology control, its owner, the system that performs it and the record that proves it ran. Open-source tools such as Wazuh, Fleet, GLPI and Zammad can produce some of that evidence, but they must be configured for your environment and their outputs reviewed on a set schedule, so confirm the scope and retention settings with your auditor before you rely on them.
Which systems and teams fall under CC5.2 technology general controls
CC5.2 covers the technology that automated business processes depend on, so the boundary of the examination is drawn by the system description and the services in scope. Each decision below changes which technology controls the auditor samples and what evidence the organization must keep.
Production infrastructure and hosting
Every production environment that runs in-scope services is a candidate for CC5.2 controls: cloud accounts, clusters, databases, network segments and the management planes that change them. Check whether staging, disaster recovery and build environments hold customer data or can alter production, because an environment that can reach production usually belongs in scope. Confirm with the auditor how the system description names these components so the controls you test match what the report claims.
Identity and access tooling
The directories, single sign-on providers, privileged access tools and secrets stores decide who can change technology in scope, so they are controlled technology in their own right. Include the administrative consoles for these systems, not only the applications that users log into. Document which platform holds the authoritative user list, since the auditor will sample joiner and leaver evidence from it.
Endpoints used to administer systems
Laptops and workstations that reach production, source code or identity consoles are part of the technology environment even when they sit outside the data center. Decide whether all company devices or only administrator devices are in scope, and state the rule in the system description. Configuration checks on those devices give evidence that baseline settings were applied and are still in place.
Ticketing and change systems
The systems that record requests, approvals, incidents and changes are the evidence trail for the technology controls, so the auditor will treat them as in scope when they support in-scope processes. Decide which queues or projects are covered and whether emergency changes flow through the same tool. Confirm that the tool can export complete histories, because gaps in those histories are a common source of exceptions.
In-scope third-party platforms
Hosted services that store, process or transmit customer data, such as code hosting, logging, email and payroll, can be carved out as subservice organizations or included with their own controls. The choice changes which vendor reports you collect and which complementary controls you describe. Review each vendor's most recent SOC report and bridge its gaps to your own controls, and confirm the treatment with your CPA firm before fieldwork begins.
How an assessor tests technology general controls
An assessor tests CC5.2 by tracing the dependency between business processes and the technology controls beneath them, then checking that the controls exist and, in a Type 2, that they worked throughout the period. The starting point is the control matrix. The assessor reads each technology general control, such as access provisioning on the production environment, change approval for infrastructure, or patching of the systems that run the application, and asks which automated business process relies on it. A billing run that calculates invoices from a database is only as reliable as the access restrictions on that database and the change controls over the code that performs the calculation. Where a process depends on a technology control that is missing from the matrix, the assessor will raise that gap before testing begins.
In a Type 1 examination, the assessor inspects design. The question is whether each technology general control, as described in the system description, is suitably designed to address the risk it targets and whether it is in place on the examination date. Typical evidence is the configuration of the identity provider, the written procedure for infrastructure changes, the scanning policy for endpoints, and a walkthrough in which the control owner explains the activity and the assessor observes or inspects a single instance. In a Type 2 examination, the assessor also tests operating effectiveness across the observation period by selecting items from the population of control performances and inspecting the records that show each one happened as described. The population, sample selection and timing are set by the auditor, so organizations should confirm with their CPA firm how it will treat automated controls, where a single configuration check may cover the whole period if change management over that configuration is also effective.
The assessor does not verify management's claims independently of the people who run the systems. Under the attestation standards, the service auditor obtains written representations from management, including management's assertion about the description and the design and operation of controls, and the representation letter is signed by the organization's responsible executives. Those representations are the basis for many inquiries, so any inaccuracy in them can invalidate the opinion. Before fieldwork, confirm that the owner of each technology general control can explain it, point to where its evidence lives, and confirm that the description matches what the systems actually do. Ask your CPA firm which of your technology controls it expects to rely on directly and which it will test with additional procedures.
What the assessor asks for and where findings come from
Infrastructure controls cover the servers, containers, network devices and cloud accounts that run the automated processes in scope. An assessor typically asks how the organization decides which configuration baseline applies to each component, who approved it, and how drift from that baseline is detected and resolved. For a Type 2 examination, the assessor will want to see that the checks ran across the observation period, not only on the day of the walkthrough.
- Baseline selection: a written, approved configuration standard for each platform type, with a named owner and a review date.
- Continuous checks: scan or query output showing that endpoints and servers were evaluated against the baseline, with dates.
- Exception handling: records of failing items, the remediation taken, and the approval for any accepted deviation.
- Infrastructure as code: version history showing who changed the configuration and whether changes passed review.
- Common findings: baselines that were written but never reviewed after the platform changed, and scans that ran but whose results nobody signed off.
Before the examination, confirm that every in-scope platform has a baseline, that the scan scope matches the asset inventory, and that someone can explain each exception without searching for it.
Security management controls govern how the organization runs its technology day to day: who owns each platform, how requests are logged and prioritized, and how security tasks are assigned and closed. The assessor looks for a process that a reviewer can follow from start to finish, with records created at the time the work happened rather than reconstructed later for the audit.
- Ownership: an asset register that names an accountable owner for each system and the security tasks that belong to it.
- Ticket trail: tickets for security requests, incidents and problems, with timestamps, assignees and closure notes.
- Policy compliance views: periodic reports showing which devices pass or fail the organization's stated policies, and what happened to the failures.
- Review cadence: evidence that management reviewed these reports and followed up on open items.
- Common findings: tickets closed without a recorded resolution, and asset registers that omit systems added through cloud accounts or shadow deployments.
Before the examination, pick a sample of recent security tickets and confirm each one can be traced to an owner, a decision and a closure date.
Acquisition, development and maintenance controls cover how new technology is bought or built, how it is approved, and how it is kept current. The points of focus connect this area to change management in CC8, so the assessor will often trace a purchase or build decision into the change records that followed. The question is whether the organization reviewed the technology before it became part of the environment.
- Acquisition reviews: documented security and business review of new tools or services before purchase or deployment, with the reviewer named.
- Change linkage: each production change tied to an approved request, testing evidence and a reviewer who was not the author.
- Maintenance records: patch and upgrade records for platforms, including the reason for deferring any update.
- Ticket references: changes in the repository or deployment pipeline that reference the ticket that authorized them.
- Common findings: undocumented acquisition reviews for tools adopted by individual teams, and changes deployed with no ticket reference, which breaks the trail from authorization to deployment.
Before the examination, list the technology added in the observation period and confirm each addition has an approval record and a matching change ticket.
How to implement CC5.2 controls step by step
This sequence moves from understanding which business processes depend on technology to a documented, owned and monitored set of general controls, with a record of each output that an auditor can test.
Map business processes to their technology dependencies
Start by listing the business processes that matter to the service commitments in scope, such as customer onboarding, billing, data processing and support access. For each process, record the systems, cloud accounts, identity providers, code repositories, pipelines and third-party services it relies on. Assign a business owner and a technical owner to each dependency. The output is a dependency map that shows where a failure in technology would break a process, which is the link CC5.2 asks the organization to consider. The step is complete when the process owners confirm the map matches how work actually flows.
Select general controls for each focus area
Using the dependency map, choose general control activities across the three areas named in the criterion: technology infrastructure, security management processes, and technology acquisition, development and maintenance. Draw on the CC6 access, CC7 system operations and CC8 change management criteria for the more specific expectations in each area. Record the chosen controls in the control matrix with the criterion they support, the system they cover and the risk they reduce. The output is a control matrix entry for each general control. Confirm with your assessor which points of focus you have addressed and why any were left out.
Set control owners, frequency and evidence requirements
For each control matrix entry, name one accountable owner who can perform or approve the control, and state how often it runs, such as continuously, on each change or on a periodic review cycle. Write down the evidence the control produces, for example an exported configuration report, an approved access review or a closed ticket. Check that no owner is also the only person who reviews their own work where segregation matters. The output is an owner and evidence column in the control matrix that a reviewer can use without asking follow-up questions.
Deploy configuration baselines and endpoint checks
Turn the infrastructure and endpoint controls into running checks. Security Configuration Assessment in Wazuh (GPL-2.0-only) scans monitored endpoints against YAML policies, mostly based on CIS benchmarks and extendable with custom policies, and reports misconfigurations with remediation advice. Fleet (MIT) policies ask yes or no osquery questions of devices, and its policies page shows which devices pass or fail each one. Test each policy on a sample device before relying on it, and confirm that the tool's scope covers the endpoints in your system description. The output is a set of active policies and a dated export of pass and fail results.
Route requests and changes through a ticketing workflow
Configure a ticketing system so that access requests, configuration exceptions, change requests and incidents each follow a defined path with an approver and a closure step. GLPI (GPL-3.0-or-later) Assistance module supports tickets, problems and changes following ITIL practices, with plannings, statistics and a Kanban view. Zammad (AGPL-3.0-only) consolidates customer communication from email, chat, telephone and social media into one ticket system, which suits customer-facing requests. Decide which tool is the system of record for each request type so evidence is not split across chat threads. The output is a documented workflow and a sample of tickets that show request, approval and closure.
Review failures and track remediation to closure
Set a routine in which the control owner reviews failed policy results and open tickets, decides whether each failure is a true exception or a configuration to fix, and records the decision. Each remediation should link back to the control and to the ticket that closed it. Escalate repeated failures on the same control, because that pattern is what an auditor will question. The output is a review record for each cycle that lists failures, decisions, owners and closure dates.
Document the control narrative and test it before the examination
Write a control narrative for each general control that describes the process, the tool, the owner, the frequency, the evidence and the exception path, in terms the auditor can follow. Then run an internal walkthrough: pick one instance of each control, trace it from trigger to evidence and check that the record is complete. Ask whether any control depends on a subservice organization, and if so, document the complementary controls that the customer or the provider must perform. The output is a set of control narratives and internal walkthrough notes that show each control operating as described.
Configuration baselines and monitoring that produce evidence
Wazuh's Security Configuration Assessment scans monitored endpoints for misconfigurations using YAML policies. Most of the shipped policies are based on CIS benchmarks, and teams can add custom policies. The checks cover files, directories, registry keys and running processes, and the scan recommends remediation for each finding. For CC5.2, this matters because the organization's own baseline becomes a repeatable, machine-run test rather than a periodic manual review. The scan results form a record of what was tested, on which endpoints, and when.
- Policy scope: Confirm which shipped policies apply to your operating systems and which need custom YAML checks for internal standards.
- Coverage of monitored endpoints: Check which endpoints are enrolled and which are missing, since an unscanned host produces no evidence.
- File, registry and process checks: Map each check to a baseline statement in your configuration standard so the auditor can trace the link.
- Remediation recommendations: Treat recommendations as input to a ticket, not as completed fixes.
- Retention of scan output: Keep dated results so an auditor can sample the period under review.
Before relying on this evidence, confirm with your own environment that the policies match the baseline you actually approved.
Fleet policies ask yes or no questions of devices, written as osquery queries. The policies page shows which devices in each fleet pass or fail each policy. This gives the team a device-level view of whether a control condition holds today, such as whether a required setting is present or a prohibited condition is absent. Because the answer is recorded per device, the output can show both the population tested and the exceptions, which is the shape of evidence that technology controls depend on.
- Question design: Write each policy as a specific yes or no statement tied to one control objective, so a failure has a clear meaning.
- Population per fleet: Record which fleet a policy applies to, since a policy that covers the wrong group will pass for the wrong reason.
- Pass and fail snapshots: Capture the policies page at intervals or export results so the period is documented, not only the current state.
- Failing devices: Each failure needs an owner, a fix or an accepted exception, and a closure date.
- Query behavior: Test each policy on a known compliant and a known non-compliant device before relying on it.
Confirm with the vendor and your own testing exactly which results are exported and how they are timestamped.
Neither a configuration scan nor a policy page is a control on its own. The control is the process that reviews the results, decides what each failure means, and records the action taken. Auditors commonly look for evidence that someone reviewed the output in the period, that failures were investigated, and that the fix or exception was approved by someone other than the person doing the work. The scan and query tools produce the raw material; the team supplies the judgment and the record.
- Review cadence: Define how often a named person reviews configuration and policy results, and keep proof of each review.
- False positives and accepted risk: Document why a finding is not a defect, and who approved the exception.
- Ticketing link: Open a ticket for each material failure in your service management system, such as GLPI's Assistance module or Zammad, and reference it in the result record.
- Trend tracking: Note repeat failures on the same device or policy, since they point to a root cause rather than a one-off drift.
- Segregation of duties: Ensure the person approving a remediation is not the only person who configured the device.
Check with your auditor how they expect review evidence to be sampled before you finalize the review workflow.
Evidence that passes a CC5.2 test
An auditor testing CC5.2 looks for proof that technology general controls were selected, designed and operated, not just described. The cards below cover the artifacts that carry that proof and who must sign off on each one between audits.
Technology control matrix
The matrix maps each technology general control to the business process it supports, the system it runs on, the owner, the frequency and the evidence produced. Auditors use it to trace CC5.2 from the stated objective to a testable control. Keep it under version control, review it at least once a year and after any significant platform change, and have the control owner and the security lead approve each revision.
Configuration baseline reports
Baseline reports show the approved configuration for servers, endpoints and cloud resources, and the scan results against it. Wazuh Security Configuration Assessment can scan monitored endpoints against YAML policies, mostly based on CIS benchmarks, and recommend remediation. Export the scan history on a set schedule, record accepted deviations with a named approver, and confirm that the baseline itself changed only through an approved change.
Device policy results
Device policy results show whether managed endpoints meet required settings such as disk encryption, screen lock or patch level. Fleet policies are yes or no osquery questions, and its policies page shows which devices are passing or failing each one. Capture dated snapshots of passing and failing counts, and keep the record of how each failing device was remediated or excepted, with the reviewer's name.
Change and acquisition tickets
Each change to a technology platform and each new purchase or build should leave a ticket showing the request, the risk assessment, the testing, the approval and the closure date. Auditors sample these to confirm that controls operate as designed. GLPI's Assistance module supports tickets, problems and changes following ITIL practices, with a Kanban view. Confirm that approvers are independent of the person who made the change where the risk warrants it.
Access and review records
Periodic reviews of administrator access to infrastructure, security tools and the ticketing system show that technology controls are reviewed by someone other than the operator. Record the population reviewed, the date, the reviewer, the decisions and the removals made. Reviews should cover the tools that generate the other evidence, since a log of changes is weaker if the people who can edit that log are unreviewed.
Exception and remediation log
The exception log lists every failed control test, accepted deviation and overdue remediation, with an owner, a risk rating and a closure date. Auditors read it to judge whether management notices control failures and corrects them. Zammad can route vendor and internal requests into one ticket system, which helps keep follow-up items traceable. Ask the auditor early how exceptions will be treated in the Type 2 period.
What meeting CC5.2 costs in money and effort
This table breaks down the cost components of meeting CC5.2 by who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to structure a request for quote and to see where self-hosted open-source tools remove license spend, while the engineering and evidence work stays in place.
| Cost component | Who is paid or who does the work | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Tooling or licenses | Software vendors for commercial configuration, ticketing or endpoint tools | Recurring (subscription or support) | Choosing self-hosted open source such as Wazuh, Fleet, GLPI or Zammad removes license fees, but support and hosting still need budget; confirm vendor terms |
| Engineering time to configure controls | Internal platform or IT staff, or an implementation partner under a written scope | One-time, with later changes | Number of systems in scope, number of configuration baselines, and how much existing documentation of technology controls already exists |
| Policy and technology control design | Internal compliance lead, security engineers, or an outside consultant | One-time, then revised | Number of technology processes, whether acquisition, development and maintenance procedures are already written, and how many owners must sign off |
| Evidence upkeep | Internal operations staff who run scans, reviews and ticket exports | Recurring, through the full examination period | Frequency of configuration scans, how much evidence is automated versus screenshot-based, and whether change and ticket records are centralized |
| Readiness assessment or external review | Independent consultant or the CPA firm, if engaged before fieldwork | Optional, one-time per readiness cycle | Maturity of the control environment, number of gaps found, and whether the readiness review covers CC5.2 only or the full criteria set |
| Auditor testing effort | The independent CPA firm that examines the controls | Recurring for Type 2 observation periods | Sample sizes, population sizes for change tickets and configuration reviews, and the number of exceptions found during testing |
| Remediation of exceptions | Internal engineers and, where needed, the implementation partner | One-time per exception, but can repeat | Number of configuration deviations, unmanaged systems, and changes made outside the ticket process |
Who owns, who prepares and who attests CC5.2
Your organization owns CC5.2. Management decides which technology general controls support its objectives, approves them, and accepts the residual risk when a control is weaker than the ideal. Those decisions have to be made by people inside the company, recorded, and tied to the risk assessment. An implementation partner can draft options, but it cannot accept risk or sign off on the control design on your behalf.
- Control selection: Management chooses which infrastructure, security management and change-related controls apply to the in-scope system, and documents why.
- Approvals: Named owners approve access to the technology environment, configuration baselines and changes to automated business processes.
- Ongoing operation: Staff review alerts, exceptions and tickets, and follow up on failed checks.
- Management's description: Your team writes and stands behind the system description and the assertion the examination depends on.
- Vendor and staff accountability: Owners maintain the list of tools, platform dependencies and personnel responsible for each control.
Before the examination, confirm that every control has a named owner who can explain it to the auditor without a consultant in the room.
An implementation partner such as DeployOpen prepares the systems, configuration and evidence that technology general controls depend on. In a self-hosted deployment, that usually means building the tooling inside your cloud accounts or data centers, setting configuration baselines, wiring alerts and tickets into a workflow, and producing records the auditor can sample. The partner works to the scope you agree in writing, and the controls remain yours.
- Configuration and hardening: The partner sets up baselines, for example with a configuration assessment tool such as Wazuh, and documents the settings it applies.
- Policy checks: Compliance queries on devices, for example Fleet policies, are configured and their pass or fail history retained.
- Ticketing workflows: Change and incident records are set up in a system such as GLPI or Zammad so that approvals are visible.
- Evidence packs: The partner arranges exports, screenshots and logs in a form that maps to the control matrix.
- Documentation and handover: Runbooks explain how each control operates, who runs it and what it produces.
Ask the partner which tasks it will not do. A partner that writes your control narratives and then also tests them has blurred the line your auditor will check.
The CPA firm is the service auditor. It examines the description of your system and the design and, for a Type 2 report, the operating effectiveness of your controls over a period. Only the firm issues the SOC 2 report and its opinion. The auditor must be independent of the organization, which limits what it can build, configure or write for you while also performing the examination.
- Testing: The auditor selects samples, requests evidence and inspects configurations, tickets and logs for CC5.2 controls.
- Representations: Under the attestation standard that governs SOC 2, the auditor obtains written representations from management, so your team must be ready to sign them.
- Exceptions: Any deviation the auditor finds is reported in the opinion or as an exception, not quietly fixed by the auditor.
- Independence limits: If the same firm designed the controls, the independence question must be resolved before fieldwork starts.
- Engagement terms: The engagement letter defines scope, responsibilities and the period covered.
Confirm with each candidate firm what advice it can give during readiness and what it will need to exclude from its own examination.
Where organizations fall short on technology general controls
Most CC5.2 findings come from controls that exist on paper or in a tool but have no accountable owner, no linked records, and no review cycle. The gaps below cluster around how technology is acquired, changed and configured, and each one has a concrete way to close it before an examination period begins.
Controls that live only in tools
A scanner, ticketing system or dashboard may run a control automatically, yet nobody is named to review its output, approve exceptions or answer for failures. An assessor will ask who acts on a failing result and for proof that someone did. To close the gap, assign a named owner to every technology control, record the owner in the control matrix, and keep a dated log of reviews and actions taken on flagged items. Confirm each tool's alerting and export options in its own documentation before relying on them as evidence.
Change records not linked to deployments
A change ticket that says a release was approved does not show that the approved change is the one that reached production. Auditors commonly sample a deployment and trace it back to an approval, and a gap in that chain becomes an exception. Close it by requiring the change identifier in the pipeline or deployment record, blocking deployments that lack an approved ticket, and reconciling tickets against deployment logs each period. Ask your platform team which systems can enforce this automatically and which need a manual reconciliation.
Technology acquired without security review
New software, cloud services and open-source components often enter the environment through a team purchase or a quick download, with no security or data review. Later, the organization cannot show what it approved or what data the product touches. Close the gap with an intake step for every new technology that records the owner, data classification, hosting location, access model and security requirements before purchase or deployment. Keep the intake records with the vendor files so they can be sampled as evidence.
Configuration drift with no review
Servers, containers and endpoints slowly move away from their approved baseline through manual fixes, emergency changes and unmanaged updates. Without periodic comparison, no one notices until an audit or incident. Close the gap by defining a hardened baseline for each system class, running configuration assessments against it on a set schedule, and routing deviations into the change or incident process. Wazuh's Security Configuration Assessment checks monitored endpoints against YAML policies, mostly based on CIS benchmarks, and recommends remediation, which can serve as this recurring review once its results are assigned and tracked.
Device checks that nobody tracks
Endpoint policies such as disk encryption, screen lock or required agents can pass or fail across a fleet without anyone reviewing the failing devices. A policy that exists but has no follow-up is weak evidence of a working control. Close the gap by writing each policy as a yes or no check, deciding who reviews failing devices and how quickly, and recording remediation or exceptions with approval. Fleet's policies page shows which devices pass or fail each policy, which can feed that review if your team confirms the query coverage for your fleet.
Common questions about CC5.2 technology general controls
What drives the effort of meeting CC5.2 technology general controls?
The main driver is how many technology systems support the in-scope business processes and how many of them are managed by hand. CC5.2 asks the organization to select and develop general control activities over technology infrastructure, security management, and technology acquisition, development and maintenance, so every system that runs or feeds a process in scope needs a documented control and evidence behind it. Effort rises when infrastructure is built by hand, when change and access records live in chat threads rather than tickets, and when the team has not mapped which technology supports which business process. Effort falls when configuration is codified, approvals are recorded in one ticketing system, and the scope is drawn tightly. Ask any consultant to show the dependency map between business processes and technology controls before quoting.
Can a small team meet CC5.2 without outside help?
Often yes, provided someone owns the work and the team has the time to document it. CC5.2 is a design question first: the organization must decide which technology controls support its objectives and write them down. A small team with a clear system description, a ticketing tool for changes and access requests, and a configuration assessment tool can cover much of it internally. Outside help is most useful for the parts that are hard to self-assess, such as independent review of the control design, hardening of self-hosted platforms, and preparing evidence in a form the auditor will accept. Your CPA firm will test the controls, so do not assume the implementation partner or your internal reviewer can stand in for that independence.
How long does CC5.2 work take and what does it need from staff?
The timeline depends on the size of the in-scope environment, the maturity of current processes, and how far the observation period in a Type 2 report must run. The AICPA's 2017 Trust Services Criteria do not set a calendar duration for designing these controls, so treat any published estimate with caution and ask your CPA firm and implementation partner to state their assumptions in writing. Staff needs typically include an engineering owner for infrastructure and deployment, a security owner for configuration and access, an operations owner for tickets and changes, and a leader who signs off on the control descriptions. Confirm the time commitment for each role during scoping, since the people who build the systems are often the same people who must document them.
Can an implementation partner issue the SOC 2 report for CC5.2?
No. Only an independent CPA firm can examine the controls and issue a SOC 2 report. An implementation partner such as DeployOpen plans, implements, hardens and documents the self-hosted platforms that support technology general controls, and prepares the evidence the auditor will request. The organization remains responsible for its own controls and for management's written assertion and representation letter. When you select a partner, confirm that the CPA firm is independent of the partner and that the engagement letter is signed directly with the firm. Ask the firm which evidence formats it accepts before implementation begins.
How does CC5.2 differ from CC5.1 and CC5.3?
CC5.1 covers how control activities are selected and designed so that they reduce risks to acceptable levels, including the mix of control types and segregation of duties. CC5.2 narrows that focus to general controls over technology, meaning the infrastructure, security management, and acquisition, development and maintenance controls that support automated business processes. CC5.3 covers how those controls are deployed through policies that set expectations and procedures that carry them out, including ownership, timely performance and periodic reassessment of policies. In practice, CC5.1 decides what the controls are, CC5.2 decides which technology controls must exist, and CC5.3 writes them into policies and procedures that staff follow and auditors can test.
Which open-source tools can produce evidence for CC5.2 technology controls?
Several open-source tools can generate records that support CC5.2 controls, but each one covers only part of the picture and must be confirmed against your own environment. Wazuh's Security Configuration Assessment checks monitored endpoints against YAML policies, mostly based on CIS benchmarks and extendable with custom policies, and reports misconfigurations with remediation advice. Fleet policies are yes or no osquery questions asked of devices, and its policies page shows which devices pass or fail each one. GLPI's Assistance module supports tickets, problems and changes following ITIL practices, which can hold change approvals. Zammad can hold customer-facing tickets. Confirm with each vendor which features your version provides, and keep exported records as dated evidence.
What should a buyer ask for in a quote for CC5.2 work?
Ask for a written scope that lists the in-scope systems, the business processes they support, the controls to be designed or documented, the evidence to be delivered, and the acceptance criteria. Request a breakdown that separates one-time work, such as design, hardening and documentation, from recurring work, such as monitoring, evidence collection and upgrades. Ask who performs each task, what staff time you must supply, and which assumptions the price depends on, including the number of systems and environments. Also ask how changes to scope are priced and approved. DeployOpen does not publish a price list, and its work is fixed-scope, so a quote follows from that written scope.
How DeployOpen prepares CC5.2 evidence
This sequence turns the technology general controls a client chooses into a scoped, implemented and documented set of self-hosted systems, with evidence the client owns and an independent auditor can test. DeployOpen prepares that material; the client remains responsible for its controls and the auditor alone issues any report.
Agree the scope in writing
DeployOpen and the client agree in writing which systems, cloud accounts, data centers or air-gapped networks, and which technology general control areas are in scope, such as infrastructure, security management, and acquisition, development and maintenance of technology. The client's CPA firm should review the boundary before work starts, because the scope decides which controls are tested. The step closes with a signed scope document, deliverables and timeline that both parties accept.
Map technology controls to business processes
Working with the client's control owners, DeployOpen identifies which automated business processes depend on each in-scope system, such as provisioning, deployment, logging or ticket handling. The output is a control matrix that links each general control to the criterion it supports, the system it runs on, and the person who owns it. The client approves the matrix, which becomes the reference for every later step.
Build and harden the self-hosted platforms
DeployOpen installs and configures the open-source platforms inside the client's own infrastructure, applying the client's standards for baselines, access, logging and backups. Infrastructure is defined as code where practical so that configuration can be reviewed and reproduced. The step closes with a build record that shows the versions deployed and the hardening applied, which the client's team checks against its own requirements.
Configure technology control monitoring
DeployOpen sets up tools that check configuration and device state against stated policies. Examples include a configuration assessment scanner that evaluates endpoints against YAML policies, and a device policy tool that asks pass or fail questions through osquery queries. Policies are written with the client so that each rule maps to a control in the matrix. The output is a tested set of policies and a sample report showing passing and failing results.
Set up change and service management records
DeployOpen configures the ticketing and change workflows the client uses to request, approve and track changes to technology, using a service management module with change records or a helpdesk for request handling. Required approval steps and fields are set so that every change leaves a traceable record. The client confirms that the workflow matches its documented change procedure before go-live.
Collect and package control evidence
DeployOpen defines where each piece of evidence comes from, how often it is exported, and where it is retained, then sets up collection so that configuration snapshots, policy results, change tickets and access records are kept for the observation period. Evidence is labeled by control and date. The client reviews a sample package to confirm that it is complete and readable by someone outside the engineering team.
Hand over documentation and test readiness
DeployOpen delivers system documentation, runbooks and the evidence index, and walks the client's control owners through how each control operates and where its evidence sits. The client or its consultant may run a readiness walkthrough before the examination. The auditor, not DeployOpen, performs testing, selects samples and issues any report or opinion. The step closes with signed handover acceptance from the client.
