Imagine someone on your team removes an approval step to make a routine process easier. The change looks sensible to the people doing the work. Then, at the next risk meeting, you discover that the step was there to protect a customer commitment. Nobody asked the control owner before it disappeared.
That’s the kind of situation AICPA criterion CC3.4 asks you to think about: changes that could significantly affect internal control. You need a reliable way to bring business developments to the people who understand your controls and commitments. Sometimes they’ll confirm the existing arrangements still work. Sometimes they’ll find an assumption you need to revisit.
Distinguish this assessment from technical change control
You may already have a process for approving, testing, and releasing technical changes. CC8.1 addresses the controlled implementation of changes to infrastructure, data, software, and procedures. CC3.4 asks you to step back and consider how developments inside or outside your business could affect the overall system of internal control.
A new service, customer requirement, acquisition, or leadership approach can change what you need your controls to accomplish. Your engineering release process may provide useful information, but a sales commitment, HR process redesign, or regulatory change might never pass through it.
Suppose you’re moving to a new cloud provider. Technical change control helps you manage the migration itself. Your CC3.4 assessment considers the effect on customer data, contracts, dependencies, and control responsibilities. Even a smooth migration can leave you unable to meet a promise if nobody checks those wider consequences.
Put risk owners into the decisions already being made
Start with the decisions your business already makes. Vendor onboarding, project approvals, leadership meetings, and customer negotiations give you natural places to notice significant changes. Bring the person responsible for risk into those conversations while there’s still time to influence the decision.
In a small company, that may be you or another founder. As you grow, a cross-functional risk or security committee can bring together leaders who know what’s changing in their departments. Help them see how their decisions affect the rest of the business. HR, finance, operations, and sales all have information your IT team may never see.
Give control ownership to people who understand the work and are involved when it changes. Your HR leader may notice a hiring or termination change sooner than a CTO who owns that control only on paper. Make sure owners know why the control exists and when to involve other teams.
Give employees permission to raise a concern before they can prove the full impact. In our opening example, someone who says the shortcut might remove a safeguard is bringing you useful information. The responsible people can then assess it together.
Ask about the business before asking about controls
Make room on your agenda for questions such as “What is leadership planning?” and “What are customers asking us to change?” Then work through the effect on controls and commitments. If you ask people to classify the control impact before they speak, you may never hear about developments they haven’t yet recognized as relevant.
Here are some prompts you can bring into that discussion:
- Leadership initiatives and changes in management, responsibilities or expectations for how controls operate.
- New services, markets, acquisitions and other business-model changes, with confidential matters shared only with authorized participants.
- Customer-initiated requirements, onboarding and offboarding, including obligations that may require contractual review.
- New tools, architecture, vendors and changes in relationships with business partners.
- Regulatory, economic, market or physical-environment developments that could affect the service. AI adoption can introduce several of these questions at once.
- Changes in threats and vulnerabilities that could alter the likelihood or impact of a risk, even when the company's own processes have not changed.
AICPA's revised points of focus cover six areas: the external environment, business model, leadership, systems and technology, vendor and partner relationships, and threats and vulnerabilities. The agenda above translates those areas into business discussions. It is an illustrative approach, not a prescribed committee structure or a separate mandatory control for each point.
Choose a review frequency that fits how you make decisions and how quickly exposure can change. A major project may already need finance approval and a project team, giving you an opportunity to involve the committee. Make sure urgent threats and rapidly changing obligations can reach the right people sooner.
Follow the effect on customer systems and data
Take the proposed change and follow one affected activity through the new arrangement. What information moves? Who can access it? Can you still meet the commitments you’ve made? Walking through the work is often more useful than starting with a blank control checklist.
For a new supplier, follow the relevant data beyond your immediate provider. Does another company process it on their behalf? Consider processing locations, access, encryption, and contractual obligations through that chain. Match the depth of your review to the exposure and your customer promises.
Be clear about what you’ve established and what you still need to verify. A contractual statement and a demonstrated technical capability answer different questions. If you depend on a particular restriction to meet a customer commitment, confirm that the proposed arrangement can support it.
A bootstrapped five-person company with two founders
Picture yourself as one of two founders in a five-person software company. You’re replacing the customer support tool. You lead product and engineering, your cofounder manages operations and customers, and one of your three employees handles support. Bring that employee into the planning conversation so you can understand the actual workflow.
You review access to uploaded customer files and where the provider processes them. Your cofounder checks the retention and deletion commitments you’ve made. Together, you ask whether another company will analyze the attachments. You’ve brought the business obligations into the decision before any customer data moves.
Suppose the configuration fits your existing commitments and controls. Record what you considered, who participated, and why no further action is needed. If deletion behavior is still uncertain, assign that question and resolve it before transferring data that depends on the requirement.
You can update the relevant vendor or data-handling risk in Vanta’s risk register, identify its owner, and retain the assessment. That gives you a place to revisit the decision as the service changes. You and your cofounder still need to review the proposed arrangement and reach the conclusion.
Keep enough evidence to explain your reasoning: the meeting note, relevant vendor information, customer obligation, and any follow-up. You may not need a large committee packet, but sensitive information or complex contractual requirements can justify more extensive review and specialist advice even with five people.
At 100 people, connect customer requirements to operations
Now imagine you’re part of a 100-person service provider. Operations, IT, HR, finance, and customer delivery meet on your security committee. You make a point of asking about customer initiatives as well as projects your own company has started.
Operations explains that a customer is introducing payment keypads your staff will use. The customer expects you to track and return the equipment. IT walks through device assignment, and HR explains what happens when an employee leaves.
You already have inventory and return controls, but the discussion reveals that they don’t identify these customer-owned keypads. IT adds the necessary inventory details, while HR and operations update the departure process. Together, you agree how to check that the revised process works. This fictional example shows a control adjustment prompted by a customer requirement; it isn’t a complete payment-card compliance assessment.
Use the same conversation for customer onboarding and offboarding. When a relationship ends, you may have obligations for data, access, or equipment that your standard process doesn’t cover. Bring the relevant contract into the review so you can assess the actual requirement.
In Vanta, you could connect the recorded risk with the relevant controls and use its Action Tracker to follow the agreed improvement, owner, and due date. Then have the control owner check the inventory and return process in use. That practical check gives you evidence beyond the completed task.
Retain the customer requirement, committee decision, updated procedure or inventory, assigned actions, and records showing the adjustment working. For a different initiative, you may conclude that existing controls are sufficient. Record that reasoning without inventing a remediation task just to give the meeting an action item.
At 1,000 people, include risk in major project decisions
At a fictional 1,000-person provider, you’re planning a cloud architecture change with a new analytics supplier. The project already needs finance approval, procurement work, and a project team. Build the risk review into those decisions while the proposed architecture can still change.
Ask business and technical owners which customer systems and information the supplier will support. Will data leave your environment? What can the supplier access, and do its own providers receive that data? Bring legal and customer-delivery colleagues into the discussion to interpret your commitments, while technical owners assess the safeguards.
Suppose a downstream processing location conflicts with a customer commitment. You could evaluate a permitted configuration, keep the affected data out of the service, or reconsider the proposal. If management wants to change the customer commitment, that needs its own authorized process. Approving the project doesn’t remove the existing obligation.
Once you agree on an acceptable approach, name the owners who will carry it into implementation. Record the decision and unresolved conditions, then obtain evidence that the chosen arrangement was put in place. Resolve conditions needed to meet customer commitments before the affected activity starts. If the project changes along the way, revisit the assessment.
Vanta can help you connect the risks with controls and their supporting tests or documents, so participating owners can work from a common set of records. Management still needs to evaluate the supplier chain and its effect on customers. Automated results can’t determine whether a new arrangement satisfies a particular contractual promise.
Keep the proposal, data flows, customer obligations, assessment, decision, and resulting work connected. That lets someone follow why you chose the approach. Headcount is only an illustration here; a smaller business with a complex supplier chain may need the same depth of analysis.
Carry the assessment through to the appropriate decision
CC3.4 focuses on identifying and assessing changes. If your assessment shows a control needs to change, carry the decision into the relevant operating process. CC5.3 addresses deploying control activities through policies and procedures, and technical implementation may also involve CC8.1.
Make your conclusion easy to understand. Your existing controls may be sufficient, a control may need adjustment, or an activity may need restrictions before it proceeds. Where work is warranted, identify an accountable owner and how you’ll confirm completion. Let the assessment determine the follow-up.
For significant changes, retain enough information to show what was known when the decision was made. Keep the assessment, implementation and subsequent verification dates distinct. For a SOC 2 Type 2 examination, the relevant evidence needs to show how controls operated during the examination period. A new assessment performed after the period does not demonstrate that the control operated during it.
Choose documentation and review frequency for your actual risk, complexity, and obligations, and discuss examination evidence needs with your CPA firm. Check which Vanta features your subscription and configuration support. Informed ownership and management judgment remain central to the process.
Bring the next initiative into the conversation
At your next leadership or security committee meeting, ask what’s changing for your business and its customers. Include the people who understand the affected work, then decide whether the existing controls still fit. Keep a proportionate record and follow through where action is needed.
At Genius GRC, we help you make these conversations part of a practical control program, with evidence that explains the decisions. Talk with us about your SOC 2 needs and an approach that fits your service and resources. You can explore the wider series in our SOC 2 Guide.
This article provides general guidance. The company scenarios are illustrative, not required control designs. Evaluate them with your advisers and auditor in light of your examination scope and obligations.