Give the risk a useful description
A software company records “data loss” in its risk register and rates it high. Engineering points to daily backups as the response. During a recovery exercise, the team discovers that restoring a large customer account takes longer than the recovery time promised in its contract.
The original entry gave management little basis for a decision. It did not identify the affected commitment, the recovery dependency, or the assumption that needed testing. A more useful assessment would have brought those questions forward before the exercise.
AICPA criterion CC3.2 addresses identifying risks to objectives across the organization and analyzing them as a basis for deciding how to manage those risks. In a SOC 2 examination, relate that work to the services, commitments, and trust services categories within scope. This article in our SOC 2 Guide explains a practical approach, using hypothetical companies at three sizes.
CC3.2 builds on the clear objectives discussed in CC3.1. Fraud risk receives specific attention in CC3.3, while CC3.4 addresses significant changes that can affect internal control. These topics inform the same assessment; separate criterion numbers do not require isolated registers.
Start with the service and its commitments
Gather the information people need to understand how the service works. Useful inputs include a current architecture diagram, important customer commitments, incident records, vendor dependencies, and conversations with the people who operate the service.
Follow a customer transaction or a sensitive record through the system. Where does it enter? Who can change it? Which outside services handle it? What happens when a step fails? This exercise often makes an abstract concern specific enough to assess.
For example, describe the backup concern as a scenario: a production database failure could leave the team unable to restore customer information within its agreed recovery window because the recovery procedure has not been tested at current data volumes.
That statement identifies a possible event, a weakness, and a consequence. It also suggests what evidence would improve the assessment. The team can measure a restoration instead of debating a generic risk label.
Include internal and external sources of risk. Technology failures matter, but so do staffing gaps, supplier concentration, changing customer needs, and obligations affecting the service. A vulnerability inventory is a useful input; it cannot by itself explain all the ways the organization could miss its objectives.
Look beyond the security department. Customer support may know that people exchange exports through an unapproved channel. Finance may know that a critical supplier could suspend service after a billing dispute. Operations may know that one employee is the only person able to perform a recovery step.
Make ratings understandable
Define the terms used to assess likelihood and impact. If a medium impact means a short interruption that the organization can absorb, distinguish it from an interruption that could breach a critical customer commitment. Explain assumptions and the information behind each rating.
A simple scale can be useful when people apply it consistently. A detailed numerical model can also be useful, but multiplying two uncertain estimates does not make the result precise. Keep the reasoning available so another reviewer can understand or challenge the conclusion.
Separate controls already operating from improvements merely planned. A proposed recovery automation does not reduce today's exposure. When judging the remaining risk, consider what the current safeguards actually accomplish and where uncertainty remains.
NIST's risk assessment guidance offers a structured reference for preparing, conducting, and maintaining an assessment. An organization can use relevant concepts without adopting a federal assessment process in full. Select a method that supports decisions and can be maintained with the available resources.
Put a decision behind each important entry
Give significant risks a business owner who can explain the consequences and arrange a response. The person maintaining the register may support that owner, but administrative ownership alone will not resolve a staffing shortage or fund a technical change.
For the recovery example, management could reduce the exposure through additional testing and engineering work, reconsider a service commitment before agreeing to it, or accept a limited remaining exposure with a documented explanation. Any decision must remain consistent with the company's obligations.
Record the selected action, accountable person, target date, and evidence that will show whether the action worked. Where management accepts a risk, identify who had authority to accept it and when the decision should be revisited.
A due date that moves repeatedly deserves discussion. Ask whether the temporary safeguards remain adequate and whether the original risk rating still makes sense. Keep the history rather than replacing each missed date with a new one.
A bootstrapped five-person team with two founders
Consider a bootstrapped software company with two founders and three staff members. One founder leads engineering; the other manages customers and operations. They have a single hosted product and rely on a small group of cloud vendors.
The founders could hold a focused assessment with all three staff members. Beforehand, they collect customer commitments, their system diagram, recent support issues, and vendor information. Each person explains where a failure in their work could affect customers or expose information.
They identify the untested restoration scenario and assign it to the technical founder. A staff member runs a timed recovery using an approved test environment. The other founder compares the result with customer commitments and helps decide the improvement priority.
A spreadsheet may be sufficient to record the assessment, but restrict editing appropriately and preserve dated versions. The founders could review outstanding actions during a regular operating meeting and reopen the assessment when a major customer or system change introduces new exposure.
Evidence to keep: the assessment scope, dated risk entries and rating rationale, participating reviewers, decisions, recovery test results, and completed actions. The lightweight approach fits this fictional company's circumstances; a five person business handling highly sensitive information may need deeper specialist analysis.
If the founders already use Vanta, they could manage the restoration scenario in its risk register. They can describe the risk, assign the technical founder as its owner, and document the assessment and treatment plan. During their operating review, the founders can use the register to check status and revisit the assessment as recovery results become available. They remain responsible for the rating rationale and for deciding whether the remaining risk is acceptable.
At 100 people include the teams that own the consequences
A growing service provider could appoint a risk coordinator and ask engineering, support, HR, finance, and commercial leaders to contribute. Use a common assessment method so an engineering risk and an operational risk can be compared without losing their distinct consequences.
Suppose support has added an external tool that stores customer attachments. Engineering's original diagram does not show it. The cross-functional discussion uncovers the new data flow, and support's leader becomes responsible for evaluating its use with security and legal input where needed.
The company links the resulting risk to vendor review, access restrictions, retention decisions, and any corrective work. Management reviews the remaining exposure rather than assuming that completing a questionnaire resolved it.
Evidence to keep: department contributions, source inventories, assessment approvals, supporting vendor analysis, assigned treatment work, and records of management decisions. Reconcile the register with known incidents and major projects to find material concerns that have not reached the assessment.
Where the company uses Vanta risk management, the support-tool scenario could have an owner and a treatment plan, with related work organized in its Action Tracker. The owner still needs to review whether access and retention changes address the actual data flow. A completed task or passing automated check is evidence to consider, not an automatic conclusion that the remaining risk is acceptable.
At 1,000 people look for shared dependencies
A larger provider may maintain business-unit assessments with central review. Establish common terminology and escalation thresholds while allowing local teams to describe their particular services and commitments.
Several units might each rate a shared identity provider as an acceptable dependency. A companywide review could reveal that one provider supports nearly every critical service and that recovery plans assume conflicting priorities. The aggregate exposure needs a coordinated decision.
Assign an owner to evaluate that concentration and arrange a joint exercise. Keep the underlying unit assessments available so a companywide summary does not hide a severe local consequence.
Evidence to keep: the common methodology, business-unit assessments, dependency analysis, consolidation decisions, risk-acceptance authority, and follow-up on shared actions. More entries and more committees are useful only when they improve understanding or decisions.
A central team using Vanta could retain a risk snapshot for each management review and compare recorded scenarios over time. Attach or retain the underlying dependency analysis and decisions so a summary does not obscure the reasoning. Select supported capabilities for the actual subscription and access model; software does not discover every shared dependency or replace management judgment.
Preserve the assessment history
For a SOC 2 Type 2 examination, retain evidence showing how the relevant controls operated during the examination period. A point-in-time summary alone may not demonstrate the reviews and decisions that took place throughout that period.
Keep the version of the assessment that was actually used, along with later changes and their dates. If the planned review did not happen, identify the gap and its consequences honestly. A newly completed register cannot establish that earlier reviews occurred.
Choose a review schedule suited to the service and explain when an event requires earlier attention. The meeting patterns in these examples are suggestions, not universal SOC 2 frequencies. Ask the auditor what evidence is needed for the controls and period being examined. Headcount is an illustration, not a control requirement. Data sensitivity, service criticality, architecture, obligations, and available expertise may justify more rigorous analysis at any size. Vanta is optional; a well-maintained alternative can support the same process.
Improve one risk entry first
Select a high-priority entry and ask whether its owner can explain what could happen, which commitment is affected, why the current safeguards are sufficient or insufficient, and what decision remains open.
Genius GRC helps organizations develop practical controls and organize supporting evidence. Discuss your SOC 2 needs with us to build a risk assessment approach suited to your services and resources. Continue through the SOC 2 Guide for related criteria. The next article addresses CC3.3 and the consideration of fraud risk.
This article provides general guidance. Adapt the examples to your examination scope and obligations with your advisers and auditor.