Agree on the result before assessing the risk
A software company completes every scheduled backup and reports that its recovery program is working. During a customer discussion, the team discovers that people have different expectations. Sales expects the service to return within a few hours. Engineering has planned for a full business day. Nobody has agreed which records must be restored first.
The backup reports may be accurate. They do not resolve the disagreement about the result the company needs to achieve.
AICPA CC3.1 calls for objectives clear enough to identify and assess the risks to achieving them. Its focus is the outcome the organization needs, so management can recognize what threatens that outcome and decide where to commit resources.
For SOC 2, connect those objectives to the services and trust services categories within your examination scope. Relevant sub-objectives may address security, availability, processing integrity, confidentiality, or privacy. The AICPA points of focus help interpret the criterion; they are not a separate set of mandatory controls.
This article in our SOC 2 Guide explains how to turn broad intentions into useful working objectives. The examples are hypothetical, including all suggested measurements and review schedules. Choose an approach suited to your service, obligations, and resources.
Start with the service people rely on
Before writing an objective, describe the service and the people who depend on it. Identify what customers use it for, which information it handles, and the consequences of a failure. A payroll processing service and a public brochure website will have different priorities even when they use similar technology.
Review relevant agreements, approved service descriptions, internal policies, and decisions already made by management. Ask customer-facing teams whether their explanations match those records. Resolve conflicting promises before using them as the basis for a risk assessment.
NIST's Cybersecurity Framework 2.0 offers useful planning context: consider stakeholder expectations, dependencies, and applicable obligations when deciding how to manage cybersecurity risk. That planning guidance can support the practical work below without replacing the criteria used in your SOC 2 examination.
Write down the boundaries. An objective for restoring a customer application should identify the application, relevant data, and dependencies. Clarify whether it covers production only or also a supporting service needed to bring production back online.
Make the objective usable in a decision
A useful objective gives two people enough detail to recognize the same outcome. The statement should help a manager decide whether a proposed change, exception, or investment supports that outcome.
For example, a company might define a recovery objective for a particular service as restoring its essential functions within eight hours after a declared recovery event, with no more than four hours of customer transactions lost. These figures are illustrative. Another service may require a very different target, and the company must establish how the clock starts and how successful recovery is confirmed.
Record the reasoning behind the target. Perhaps customers can tolerate a short interruption but would struggle to reconstruct missing transactions. That distinction affects backup frequency, restoration testing, and the response to a failed backup.
For each objective, consider recording:
- The service or activity covered and the intended result
- The customer promise, business need, or other obligation behind it
- The accountable owner and the people who depend on the result
- How performance will be assessed and when a shortfall needs attention
- The approval date and circumstances that should prompt reconsideration
Use numbers when they make the outcome clearer. Some objectives need a defined condition instead, such as restricting a particular customer dataset to approved support personnel. Explain how the organization determines whether that condition holds.
Keep objectives connected to the work
An objective can be met through several activities. In the recovery example, backups, restoration exercises, documented dependencies, and available responders all contribute. Completing one activity does not establish that the intended recovery result is achievable.
Walk through a realistic failure with the people doing the work. Ask what could stop the company from reaching its target. An encryption key stored only in the failed environment or an unavailable specialist may matter more than whether yesterday's backup job reported success.
Record those concerns for risk assessment and assign follow-up where needed. When resources are insufficient, management needs to decide how to address the gap. An internal decision to accept risk does not rewrite an existing customer agreement; obtain appropriate advice before changing commitments.
Avoid importing another organization's objectives without checking the assumptions. A target can look precise while depending on staff coverage, supplier capabilities, or technology your organization does not have.
A bootstrapped five-person business with two founders
Consider a bootstrapped software company with two founders and three staff members. One founder manages engineering, and the other handles sales and operations. They have no dedicated risk team.
The founders could begin with a short document covering a few important service outcomes. They review their customer agreements together and ask the three staff members to describe the tasks and dependencies needed to support those outcomes. One founder owns each objective, with a named backup for absence.
Suppose they select the illustrative recovery target above for their core application. During a walkthrough, an employee points out that customer file storage is backed up differently from the application database. The founders define which records must be recovered together and arrange a test using representative test data.
If the test takes longer than expected, they retain the result, investigate the cause, and agree on corrective work. They do not quietly change the documented target to make the test appear successful. Any revised objective needs a reasoned decision and a check against existing commitments.
Evidence to keep: approved objectives, the obligations reviewed, named owners, walkthrough notes, test results, and decisions about gaps. A small document and an existing task tracker may be enough when they are maintained consistently.
If the business already uses Vanta, the founders could upload the approved objectives and recovery-test record as document evidence, or link to the maintained files. This keeps the supporting records easy to find without creating a second operating process. An uploaded file does not establish that the recovery target is realistic; the founders still need to evaluate the result.
At 100 people: reconcile service expectations
At 100 people, different departments may optimize for different results. A customer success team wants faster responses, engineering prioritizes service reliability, and finance is concerned about rising infrastructure costs.
A company could bring the relevant service owners together to reconcile those expectations before approving objectives. For a customer reporting service, they might define when reports need to be available, what constitutes a complete report, and how an incorrect result will be identified and corrected.
The discussion exposes a dependency on an upstream data provider. The provider's delivery schedule does not reliably support the proposed customer deadline. Management evaluates a different schedule, an alternative supplier, or changes to the service design before making a new promise.
Department plans then identify the work each team owns. A review of the resulting performance checks whether the service outcome is being achieved and whether the measurement itself is trustworthy. A report showing timely delivery is misleading if it excludes failed jobs.
Evidence to keep: service objectives, approval records, the source of key commitments, dependency assessments, linked departmental actions, and reviews of performance and exceptions.
Where Vanta’s risk-management capabilities fit the team’s plan and permissions, the supplier-delivery gap could become a risk scenario with an approved treatment plan. Its Action Tracker can organize associated tasks and controls. The service owner remains responsible for deciding whether a proposed remedy actually supports the reporting deadline, rather than treating task completion as proof of success.
At 1,000 people: make shared dependencies visible
A 1,000-person provider may have acquired businesses, regional operations, and services with different customer commitments. A single companywide objective can conceal important differences.
The company could maintain a common format for objectives while allowing service-specific outcomes. Each service owner identifies critical dependencies and explains any difference from the company's general expectations. A central team checks for inconsistencies that affect shared operations.
For example, two services use the same identity platform. One promises round-the-clock access, while the other's recovery plan assumes business-hours support. The review asks whether the shared platform and responder coverage can support both services during an outage.
When management approves an expansion or acquisition, include objective alignment in the transition work. Track unresolved differences and the person responsible for addressing them. Keep service-level results visible so a healthy companywide average does not obscure a serious local shortfall.
Evidence to keep: approved service objectives, ownership records, dependency maps, documented exceptions, management decisions, and transition actions with completion evidence.
A team using Vanta could retain a risk snapshot alongside the management review to show the risk scenarios recorded at that point. Keep the approved service objectives and decisions with it: a risk snapshot does not capture every business assumption or validate the commitments. Multiple registers and advanced reporting depend on the subscription; design the process around the capabilities actually available.
Keep the history across the Type 2 period
For a SOC 2 Type 2 examination, organize dated records so reviewers can trace the objectives in effect and the related work during the examination period. Keep previous versions when objectives change, together with the reason, approval, and effective date.
Connect each significant revision to the decisions it affected. A revised recovery target may require a new test, different supplier arrangements, or additional coverage. Retaining that connection is more useful than saving several nearly identical documents without context.
Review objectives when circumstances warrant it, including a major service change, a new commitment, or evidence that an assumption was wrong. Set any routine review schedule according to the organization's risks and operating model. Headcount alone does not determine the necessary formality or frequency. A small provider handling highly sensitive data may need more rigorous objectives and evidence than a larger, simpler business. Customer commitments, regulatory obligations, service criticality, and dependencies should drive the approach. Vanta or another tool can support recordkeeping and follow-up, but neither is required by CC3.1 or a substitute for management judgment.
Put one objective to work
Choose an important service and ask its owner to explain the intended outcome, its basis, and how the company knows whether it is being achieved. Resolve any disagreement before the next risk assessment.
Genius GRC helps organizations develop practical SOC 2 controls and organize supporting evidence. Discuss your SOC 2 needs with us to connect your service objectives with a workable control program.
Continue through the SOC 2 Guide. The next article addresses CC3.2, Identifying and Analyzing Risks.
This article provides general guidance. Evaluate the examples with your advisers and auditor in the context of your examination scope and obligations.