What CC3.4 asks you to do when your organization changes
If your SOC 2 examination is approaching, the question an auditor will ask about CC3.4 is simple: when the business, its vendors, its technology or its threat picture changed, did you stop and ask whether your internal controls still worked? CC3.4 assessing significant changes is the criterion that requires an organization to identify and assess changes that could significantly affect its system of internal control. It restates COSO Principle 9, which asks for exactly that kind of change review. In plain terms, you need a repeatable point where someone looks at what has moved, decides whether the risks behind your controls moved with it, and records the answer.
Be precise about scope. CC3.4 concerns risk at the organizational level, such as a new sub-processor, a reorganized engineering team, a move to a new cloud region, a new regulatory exposure, or a newly disclosed vulnerability class in a component you depend on. The authorization, testing and deployment of an individual code or infrastructure change belongs to CC8.1. Auditors will look for both, and mixing them up in your documentation is a common reason a reviewer asks follow-up questions. Confirm the boundary with your auditor early, and write it into your control descriptions so the two criteria do not overlap.
The reason this criterion causes trouble is that the work is informal. Changes surface in Slack threads, board updates, vendor onboarding tickets and hallway conversations, and nobody owns the step of turning them into a documented reassessment. Start by choosing a named owner, a trigger list (leadership changes, new vendors, major platform decisions, material threat advisories) and a recurring review that produces a dated record. Ask your auditor what evidence format they expect, because a meeting note that lists changes and the controls they affected is usually easier to test than a general statement that changes are monitored.
Which changes and parts of the organization CC3.4 covers in a SOC 2
CC3.4 asks the organization to notice changes that could significantly weaken its internal control over the system in scope. The cards below cover the categories named in the criterion's points of focus and the scope decisions that determine which changes reach the assessment.
External environment changes
Shifts outside the company, such as new regulations, customer contract demands, changes in the threat landscape or new technology trends, can make existing controls insufficient. For CC3.4, the question is whether management records these shifts and asks what they mean for the system. Check whether the risk register is reviewed when a major customer or regulator changes its expectations, and whether the review date and the people involved are written down.
Business model changes
A move into a new market, a new pricing tier, a shift to self-hosted deployments or a change in the data the company handles can alter the risk profile of the service. Each change may bring new obligations or new kinds of data into the system boundary. Ask whether product and finance plans pass through a risk review before launch, and whether the system description is updated when the service changes.
Leadership and staffing changes
When a CISO, engineering head or the people who approve access leave or join, the control environment and the assignment of responsibilities can shift. Departures can also remove the person who knew how a control worked. Check that role changes trigger a review of owners, approval rights and access to production systems, and that the review is documented rather than handled informally.
Systems and technology changes
Adopting a new platform, migrating to a new cloud region, or replacing an identity provider changes where data lives and who can reach it. These are significant changes at the organizational level, while the testing and approval of each individual release belongs under CC8.1. Confirm that the team assesses whether a platform migration alters the system boundary, logging coverage or backup design before it goes live.
Vendor and business partner changes
Switching a hosting provider, adding a payment processor or depending on a new subservice organization can move risk outside the company's direct control. Subservice organizations that fall outside the system boundary still shape the service's controls through their own reports and carve-out handling. Check that vendor onboarding, contract renewals and acquisitions of suppliers are assessed for their effect on internal control.
Threats and vulnerabilities changes
New threat intelligence, a publicly disclosed vulnerability in a component the company runs, or a security incident can change the likelihood and impact of risks that were previously rated low. CC3.4 expects these developments to feed back into the risk assessment. Ask whether the team records a re-evaluation after a serious incident or a critical advisory, and whether scope decisions on availability or privacy categories are revisited when they change.
How to set up a change assessment process that produces evidence
This sequence turns CC3.4 from a statement of intent into a repeatable process: defined triggers, named owners, recorded assessments, and linked risk and control updates that an auditor can trace from start to finish.
Define the triggers for a change review
Write down the events that prompt an organization-level risk review, grouped under the points of focus for CC3.4: external environment shifts, business model changes, leadership changes, significant systems and technology changes, vendor and business partner changes, and new threats or vulnerabilities. Include a catch-all trigger for anything the list misses, and state how each trigger reaches the risk owner, for example through a ticket queue, a standing agenda item or a vendor-management record. The output is a short trigger register approved by management. Confirm with your auditor how they expect triggers to be documented, since the wording of the criterion is not prescriptive about format.
Assign an owner for each trigger type
Name one accountable owner for each trigger category, such as the CTO for systems and technology, the HR or people lead for leadership changes, and the vendor management lead for partner relationships. Record backups for each owner so reviews do not stall during absences. The owner is responsible for noticing the trigger, starting the assessment and closing it. The output is an ownership table that appears in the control matrix or policy, with names and roles rather than team labels alone. Auditors often ask who performs the review, so keep this table current after reorganizations.
Record each assessment with inputs and conclusions
For every trigger, open a dated assessment record that states the change, the date it was identified, the source (for example, a vendor notice, a board decision or a threat advisory), and the people consulted. Document the effect on internal control objectives, the risks that now look different, and whether the existing controls still address them. Close the record with a conclusion, even if that conclusion is that no change to risk is needed. The output is a complete record per assessment that a reviewer can read without asking the owner for background. Keep the inputs attached so the reasoning can be reconstructed.
Link significant changes to individual system changes
Cross-reference organization-level assessments with the system change records that CC8.1 covers, such as a new cloud region, a replaced identity provider or a major vendor migration. Where one organizational change produces many engineering changes, note the parent assessment in each ticket or pull request, so the trail connects the decision to the implementation. The output is a traceable link between the CC3.4 record and the change tickets it produced. This keeps the two criteria distinct while showing that risk decisions drove engineering work.
Update the risk register and control matrix
Feed each concluded assessment into the risk register that CC3.2 relies on, adding new risks, revising likelihood or impact, or retiring risks that no longer apply. Where a risk changes, check whether the mapped controls in the control matrix still address it, and add or amend controls where they do not. The output is a dated revision of the risk register and, where needed, the control matrix, with a note linking each change to the assessment that triggered it. Tools such as CISO Assistant can hold the register and control mappings, but confirm that the chosen tool records revision history in a form your auditor accepts.
Track follow-up actions to closure
Convert each action arising from an assessment into a tracked item with an owner, a status and a closure record, whether that action is a new control, a vendor reassessment or a policy update. Review open items at a set cadence chosen by management and escalate those that stall. The output is an action log showing when each item opened, what evidence closed it and who approved closure. Auditors testing a Type 2 period will look for this log to confirm that assessments led to real follow-through, so avoid closing items without evidence attached.
Review the process and retain evidence
At a interval management sets, sample completed assessments and check that triggers were captured, owners acted, records are complete and actions closed. Record the review outcome and any process fixes, then retain the records under the organization's retention policy. The output is a review note showing that the process itself is monitored, which supports the link between CC3.4 and the monitoring activities under CC4. Ask your CPA firm to confirm which sample sizes and retention periods they will test before the observation period begins.
How an assessor tests CC3.4 in a Type 2 examination
This table walks through how a service auditor typically approaches CC3.4 over an observation period, what they ask for, and where findings tend to appear. The auditor's own methodology sets the exact procedures, so use the rows as a guide to preparation rather than a script. The main takeaway is that a risk review tied to real changes across the period is what passes, while a one-time document does not.
| Test step | What the assessor does | Evidence the assessor expects | Where findings usually arise |
|---|---|---|---|
| Inquiry of management | Asks who decides whether a change is significant, what triggers a reassessment, and how leadership learns about external shifts | Named owners for risk review, a description of triggers, and meeting minutes or notes where changes were discussed | Management describes a process that the records do not show |
| Review of the risk assessment record | Reads the risk register and assessment documentation to see whether it was updated during the period | Dated versions of the risk assessment, change log entries, and revision history showing reviews | No documented trigger, or a single annual review with no interim updates |
| Sampling of changes across the period | Selects a sample of significant changes (illustrative: a new vendor, a platform migration, a leadership change) and traces each one | Change tickets or records linked to a risk review, with dates showing when the risk was assessed | Changes that were never linked to the risk register |
| Comparison against business and vendor records | Compares operational records, such as vendor onboarding, contract renewals and org charts, against the risk assessment | Vendor inventories, contract dates, organization charts and project plans matched to risk entries | Vendor or business model changes that appear in business records but not in risk reviews |
| Review after incidents | Checks whether security incidents or new vulnerabilities prompted a documented reassessment | Post-incident reviews with a risk update, and dates that show the update followed the event | Risk reviews not updated after incidents or threat intelligence changes |
| Confirmation of the period | Confirms that the procedures operated across the full observation period, not only at the start or end | Evidence spread across the period, with gaps explained by management | Long gaps in evidence with no explanation |
| Auditor methodology | Applies the firm's own sampling approach and documentation standards | Confirm with your auditor their sample sizes, evidence formats and population definitions before fieldwork | Mismatched expectations about what counts as a significant change |
Which records show an assessor that changes were assessed
An assessor testing CC3.4 needs two things in the records: proof that the organization actively looked for changes that could significantly affect internal control, and a dated record of what it decided to do about them. A slide deck saying the team "considers changes" will not carry the test. The evidence should show the review happened, when it happened, who took part, and how the outcome fed back into the risk assessment described under CC3.2 and CC3.3.
The most useful records are the ones the organization already produces. Leadership and management meeting minutes that record a discussion of a new market, a reorganization, a new executive or a shift in the business model are strong evidence, as long as the minutes name the change and the decision. A dated risk register update that links each change to the risks it affects, with a revised rating or an explicit "no change required" note, is often the single most persuasive artifact. For vendors, keep onboarding and offboarding records that show the risk review done before a new business partner gained access and the reassessment when a critical supplier was replaced. Threat intelligence and vulnerability review notes, and organizational change memos issued after leadership or structural changes, complete the picture. Confirm with your auditor how many periods of records they will sample and which change types they expect to see.
Every record should fall inside the audit period, and the auditor should be able to trace it in both directions: from a change in the external environment or the business to the risk assessment entry it updated, and from a risk entry back to the source that prompted it. Broken chains are common. Ask whether each risk register entry names a source, whether each memo has a register reference, and whether vendor reviews point to the risk entry they refreshed. Where a control runs through a GRC tool or a ticketing system, confirm that timestamps and approvals export cleanly, because undated edits to a spreadsheet are hard to defend as operating evidence.
Evidence artifacts that satisfy CC3.4 and how to keep them current
CC3.4 is tested by looking for a trail: records showing that the organization noticed significant changes, judged their effect on internal control and acted on them. The artifacts below form that trail, and each works best when it is updated on a fixed cadence rather than rebuilt before every examination.
Risk register with revision history
The risk register is the central record of how the organization's risks changed over time. Each entry should name the risk, its owner, the objective it affects and the date it was last reassessed. An auditor testing CC3.4 will compare entries from one period to the next, so the revision history must show what changed and why, not only the current rating. Keep the register in a version-controlled tool so earlier states remain retrievable. Check that a change in the external environment or business model produces a dated edit to the affected entries.
Change trigger log
A change trigger log records each event that prompted a risk review, such as a new regulation, a leadership change, a platform migration or a new subservice provider. Each entry should state the trigger, the date it was identified, the person who assessed it and the outcome, including a decision that no change to controls was needed. Feed triggers from existing sources, such as the change calendar, procurement requests and regulatory alerts, so the log is maintained as a by-product of normal work rather than a separate chore.
Leadership review minutes
Minutes from board, executive or risk committee meetings show that people with authority over internal control reviewed significant changes in risk. The minutes should record the changes presented, the discussion, and any directed actions with owners and due dates. Auditors look for evidence that review happened and that follow-up was tracked to completion. Use a standing agenda item for the risk register and change trigger log so each meeting produces a comparable record.
Vendor review records
Vendor and business partner relationships are a named point of focus under CC3.4, so the organization should keep dated reviews of key suppliers. A review records changes such as a provider acquisition, a new data location, a changed subservice organization or a revised SOC report, and states whether controls or the risk register were updated. Store these alongside the vendor inventory, and tie each review to the contract or report it examined so the link between a change and its assessment is easy to follow.
Threat and vulnerability review notes
Threats and vulnerabilities are the other half of CC3.4's point-of-focus list. Periodic review notes should summarize new threat intelligence, vulnerability trends and findings from testing, and state whether any of them changed the risk picture. Notes from security testing and vulnerability scans can serve as inputs, but the note itself must record the judgment made about significance. Keep the cadence explicit, for example a recurring review with a named owner, so gaps between reviews are visible and defensible.
Documented annual reassessment
A documented annual reassessment is a formal, complete pass over the objectives, risks and changes for the period. It confirms that the register, trigger log, minutes and vendor reviews were consistent with one another and records any gaps found. Because it is performed once a year, it is the artifact most likely to be rebuilt from scratch each time. To avoid that, use a template with fixed sections, pre-fill it from the quarterly records, and have the approver sign the completed version with its date.
What meeting CC3.4 costs in money and effort
This table breaks down the cost components of running CC3.4 change assessment, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to build a quote request and to see where open-source tooling saves license spend but not staff time.
| Cost component | Who pays or does the work | One-time or recurring | What drives it |
|---|---|---|---|
| Risk register or GRC tooling | Organization, through licenses or hosting time for a self-hosted tool | Setup is one-time; hosting and upkeep recur | Number of risks tracked, integrations with ticketing and asset inventory, whether hosting is in the organization's own cloud account |
| Staff time for horizon scanning and change reviews | Internal risk owners, security, operations and leadership | Recurring | Frequency of business, leadership and vendor changes; number of teams that report changes |
| Facilitation of the initial change assessment | Internal staff or an external facilitator, if engaged under a written scope | Mostly one-time, with periodic refreshes | Size of the organization, number of systems in scope, depth of the first assessment |
| Evidence upkeep | Internal compliance or security owner | Recurring across the observation period | Number of assessments held, whether minutes, decisions and risk updates are captured as they happen |
| Vendor and threat intelligence inputs | Organization, through subscriptions or staff time on public advisories | Often recurring | Number of vendors and business partners in scope, volume of threat sources the team monitors |
| Auditor sampling and inquiry effort | Organization prepares evidence; the independent CPA firm tests it | Recurring at each examination | Number of changes sampled, clarity of the change log, whether assessments are dated and tied to specific decisions |
| Ask in the quote | Consultant or implementation partner | Written scope | Confirm which items are in fixed scope, which are retainers, and which the organization keeps in-house |
How CISO Assistant can hold the risk register and change reviews
CISO Assistant is an open-source option for keeping the risk register that CC3.4 depends on, provided you confirm it fits your environment. It is released under the AGPL-3.0-only license and ships more than 200 frameworks, including SOC 2, with automatic mapping between frameworks. For a SOC 2 team, the practical question is whether its risk, asset, control and evidence objects can record the organizational changes your assessor will ask about: a new vendor, a leadership change, a new market, or a newly disclosed vulnerability class. Read the project's CISO Assistant README on GitHub and then test those objects in a non-production instance before you commit to the workflow.
A workable setup links each significant change to the risks it affects and to the controls that address those risks. In practice, that means recording the change as a dated entry, attaching the risk entries it reopens or creates, and noting which controls were reviewed in response, with the reviewer and the outcome. The review history is what an examiner samples when testing whether management identified and assessed changes, so every reassessment should leave a timestamped record that shows who decided what and why. Confirm whether your deployment can preserve that history without overwriting earlier risk scores, and whether exports carry the linked evidence along with the entries.
Change-triggered reviews are the part most teams must confirm rather than assume. Ask whether your instance can prompt a reassessment when a linked asset, vendor or framework requirement changes, or whether that trigger has to come from a ticketing or GRC workflow outside the tool. Because CISO Assistant is AGPL-3.0-only, check with counsel what the license requires if you modify the software, host it for users outside your organization, or offer it as part of a service to customers. DeployOpen can configure, integrate and document a self-hosted deployment within a written scope, but the risk decisions, their sign-off and the independent SOC 2 report remain with your organization and your CPA firm.
Who owns CC3.4, who can help, and where the auditor draws the line
Your organization owns CC3.4. Management must decide which changes in the external environment, business model, leadership, systems, vendor relationships and threats could significantly affect internal control, how each one is judged, and what response follows. Those judgments belong to people who understand the business and can be held accountable for them, usually a risk committee or the executives who own the objectives.
- Decision making: Name the owner of each change category and record who approved each assessment and when.
- Judgment on significance: Document why a change was or was not considered significant, including the factors weighed.
- Response decisions: Record the control adjustments, owners and due dates that follow from an assessment.
- Periodic review: Schedule reassessments and keep minutes showing that leadership reviewed the register.
- Business context: Only your people know about pending acquisitions, new markets or leadership moves before they happen.
Confirm with your team that the people named as owners can explain their decisions to an auditor without relying on a consultant.
An implementation partner can prepare the machinery that makes the assessment repeatable and visible. This work is often outsourced because it is technical and template-heavy, and it does not require the partner to make risk decisions. The partner prepares the systems and evidence; it does not set your risk appetite or sign off on your conclusions.
- Tooling setup: Configure a risk register, workflow and review reminders in a self-hosted tool your organization controls.
- Template design: Draft assessment templates that prompt for each change category and capture the decision and approver.
- Trigger definitions: Help define which events, such as a new vendor, a leadership change or a major platform migration, should open an assessment.
- Evidence packaging: Organize meeting records, register exports and approval trails so the auditor can sample them.
- Handover: Train the owners who will run the process after the engagement ends.
When engaging a partner, ask for the scope in writing, who keeps the tool and data after handover, and which deliverables are yours to keep.
The CPA firm is the independent service auditor. It plans its examination, tests whether the controls described in your system description are designed appropriately and, for a Type 2 report, operated effectively over the period. It then issues the opinion. Under the attestation framework, the firm must obtain written representations from management, which means management must stand behind its own assertion.
- Independent testing: The auditor samples assessment records, checks dates and approvals, and compares the register against other operational evidence.
- Assertion and representations: Management signs the description and representation letter, so the assessment must be authored by management.
- No authorship: An auditor who writes the assessment would be auditing its own work, which removes the independence the report depends on.
- Exceptions: Gaps, such as a missed review or an undocumented decision, appear as exceptions in the report rather than being fixed by the auditor.
- Engagement terms: Confirm in the engagement letter what the firm will test and what it expects management to provide.
Ask the firm early which preparation activities it will accept and which would compromise its independence.
Where organizations fall short on CC3.4 and how to close each gap
CC3.4 asks whether an organization notices changes that could significantly affect its internal control and responds to them. Most gaps come from a risk assessment that is treated as an annual document rather than a living input. The cards below cover the failures assessors see most often and a practical fix for each.
No defined triggers for reassessment
Many organizations reassess risk only when someone remembers to. Without written triggers, a new subprocessor, a product launch or a change in hosting region may never reach the risk assessment. Define a short list of events that force a review, such as new vendors handling customer data, material changes to the system description, new regulatory obligations, or a significant incident. Record who watches for each trigger and where the change is logged. Ask your CPA firm which triggers they expect to see documented.
Reassessment only once a year
An annual risk assessment can be accurate on the day it is signed and stale within months. Assessors look for evidence that the organization considers changes between cycles, not only at the calendar review. Pair the annual review with a standing agenda item at a recurring management or security meeting where changes are discussed and either recorded or explicitly closed. Confirm with your auditor how they expect interim reviews to appear in the Type 2 observation period.
Vendor and leadership changes missing from the register
A new cloud provider, an acquired subsidiary or a departing CISO can shift risk more than any software release, yet these changes often happen in procurement or HR and never reach the risk register. Route vendor onboarding, offboarding and executive role changes through a checklist that asks whether the risk assessment needs updating. Keep the vendor inventory and the risk register linked so a new entry cannot exist without a risk review. Ask for this linkage in any tooling you buy or build.
Threat intelligence not considered
CC3.4 includes threats and vulnerabilities as a category of change. An organization that reads vendor advisories, sector alerts or vulnerability feeds but never connects them to its risk assessment has a gap in the evidence trail. Assign an owner to review relevant threat sources on a set schedule and record which items changed the risk picture. For a self-hosted platform, include advisories for every component in the stack, not only the application itself. Confirm which sources your auditor considers reasonable for your system.
Assessments with no recorded conclusion
A common finding is a meeting note that says a change was discussed, with no record of whether it changed any risk rating, control or objective. Assessors need to see the conclusion, including the decision to take no action. For each assessed change, record the date, the change, the risks affected, the decision and the approver. This turns a discussion into evidence. Keep these records in the same place as the risk register so the auditor can trace a change to its outcome.
Questions buyers ask about CC3.4 before hiring help
How much extra effort does CC3.4 add to an existing SOC 2 program?
For most organizations that already run a risk assessment for CC3.2, CC3.4 adds a recurring review rather than a new program. The effort depends on how much of the business changes each year. The drivers are the number of significant changes in the period (new products, acquisitions, a new cloud region, a new critical vendor, a leadership change), how many people must contribute to the review, and whether the risk register is current enough to compare against. The first pass is the heaviest because someone must document a baseline. Ask a partner to quote the work as a fixed scope: the review cycle, the meetings, the register updates and the evidence the auditor will sample. The auditor's testing effort is set in the engagement letter, not by the partner.
Can a small team run CC3.4 without outside help?
Yes, if one person owns the risk register, has authority to pull in engineering, finance and leadership, and keeps a dated record of each review. A small team usually struggles less with the method than with consistency: changes are noticed informally in chat and never written down. Outside help is most useful for setting the first baseline, designing a repeatable checklist that covers the six points of focus for CC3.4 (external environment, business model, leadership, systems and technology, vendors and partners, and threats and vulnerabilities), and testing that the record would satisfy an auditor. The organization still owns the decisions.
How often should a significant-change reassessment happen?
The Trust Services Criteria do not set a fixed interval for CC3.4, so the frequency is a design decision your organization must make and justify. Many programs review on a set cadence, such as quarterly, and also trigger an ad hoc review when a defined event occurs, such as an acquisition, a major platform migration, a breach, or the loss of a key subservice organization. Your auditor will test whether the cadence you chose was followed and whether event-driven reviews happened when they should have. Confirm the cadence with your auditor before the observation period starts, because changing it mid-period creates questions.
How does CC3.4 differ from CC8.1 change management?
CC3.4 concerns changes in risk at the organizational level, such as a new market, a new leadership team, or a new threat that could affect internal control. CC8.1 concerns individual changes to infrastructure, data, software and procedures: how each one is authorized, built, tested, approved and deployed. A release pipeline with reviews and approvals supports CC8.1 but does not, by itself, show that anyone assessed whether the release changed the organization's risk. Auditors look for both. Keep the two records separate so each can be tested on its own terms.
What does an implementation partner need from our organization?
A partner needs named owners and access, not just a kickoff meeting. Typically that means the people who approve strategy and budget, the owner of the risk register, engineering and cloud leads who can describe systems and vendor dependencies, and the people who record HR, vendor and incident events. The partner also needs your existing risk assessment, change history, board or leadership meeting minutes, and the system description draft. Confirm in writing which artifacts you will provide, in what format and by when, because late inputs are a common reason fixed-scope work slips. Access should be granted under your own security rules and recorded.
Can our SOC 2 auditor prepare the CC3.4 assessment for us?
Generally no. The organization owns its controls, and an implementation partner prepares systems and evidence. The CPA firm performs the examination and issues the report, so it cannot design or prepare the controls it is going to test without creating an independence question. Ask your CPA firm what it is permitted to provide under its independence policies and the engagement letter, and ask the partner to confirm in writing what it will deliver and what stays with your team. Whatever you decide, the assessment and its approvals must come from your organization.
Which open-source tools can keep a CC3.4 record?
Many teams keep the risk register and review records in a governance tool or in a controlled document system, linked to tickets for each change. CISO Assistant, an open-source tool licensed under AGPL-3.0-only, ships with more than 200 frameworks, including SOC 2, and supports audits and compliance assessments against them with automatic mapping between frameworks. Confirm that its risk and change workflows match how your organization records significant changes before adopting it, and check whether your auditor accepts its exports as evidence. Details are in the project's README on GitHub.
How DeployOpen prepares CC3.4 evidence in your environment
DeployOpen works on CC3.4 by helping your organization define what counts as a significant change to its system of internal control, then building the monitoring, records and review routines that show those changes were identified and assessed. The organization owns its risk assessment and its control design, while DeployOpen prepares the systems and evidence an independent CPA firm will test.
How we scope
- The written scope lists which external, business, leadership, technology, vendor and threat changes are reviewed for CC3.4.
- Scope names the systems, environments and business units whose risk assessment records will be reviewed.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We set up a documented trigger list so changes such as new vendors or leadership shifts reach the risk register.
- We configure the systems that record architecture, vendor and asset changes so each entry leaves a dated trail.
- We test the routine on sample changes to confirm the assessment step happens and is recorded consistently.
How we hand over
- You receive the change-assessment procedure, trigger criteria and risk register templates written for your organization.
- Evidence packs map each risk review record to CC3.4 so your CPA firm can select samples without rebuilding the trail.
- Walkthrough sessions explain where each record lives, who approves it and how to explain it during fieldwork.
How we support
- Ongoing support and continuous review of the change routine are available as a retainer after handover.
- Retainer work can refresh trigger criteria when the business model, vendor base or threat picture shifts.
- Your CPA firm stays the only party that issues the SOC 2 report, so we confirm evidence questions with your auditor directly.
