CC3.1 Specifying objectives: SOC 2 requirements

What CC3.1 asks a SOC 2 team to write down before any risk is assessed

Your auditor has asked for the risk assessment, and the team has no written objectives to assess risk against. CC3.1 asks the organization to specify its objectives clearly enough that risks to those objectives can be identified and assessed. In practice, that means a written set of operations, reporting and compliance objectives, each stated well enough that someone could tell whether a threat would make it harder to reach. The criterion restates COSO Principle 6, and it sits at the start of the risk assessment because CC3.2 (identifying and analyzing risks), CC3.3 (fraud risk) and CC3.4 (significant changes) all measure risk against these objectives. If the objectives are missing or vague, every later risk rating is arbitrary.

The common failure is objectives that read as slogans, such as "be the most trusted platform" or "keep customer data safe.

" An assessor cannot test a slogan, and a team cannot identify a risk to one. Objectives written only for a pitch deck or investor update have the same problem: they describe ambitions rather than what the organization runs, reports and must comply with. Start by listing the service commitments in your customer contracts and the reporting you owe to customers and regulators, then write one objective per commitment with a measurable condition, such as an uptime target, a reporting deadline or a regulatory duty. Record the risk tolerance for each one, meaning how much deviation management accepts, and break larger objectives into sub-objectives that the risk assessment can examine one by one.

Which objectives a SOC 2 system needs to state

CC3.1 asks the organization to state objectives clearly enough that risks to them can be found and rated. For a SOC 2, those objectives are shaped by the service commitments made to customers and by the scoping choices made before the examination starts.

Operational objectives

These state what the service must do for customers in day-to-day operation, such as uptime targets, processing throughput or support response. They matter because the risk assessment in CC3.2 measures threats against them. Check that each operational objective is specific enough to test, and that engineering and operations leaders agree on the wording before the risk register is built.

External and internal reporting objectives

These cover what the organization reports to customers, regulators and its own leadership, and how reliable that information must be. A SaaS company that publishes uptime figures or sends billing data to customers has reporting objectives that a risk assessment must cover. Confirm who owns each report and which data feeds it.

Compliance objectives

These record the external laws, regulations and contract terms the organization must meet, such as data protection duties or customer security addenda. Stating them early lets the assessor see that legal obligations were considered as risks. Ask legal and privacy staff to confirm the list, and note where a customer contract imposes a stricter requirement than the law does.

Service commitments that shape the system

Commitments made in customer contracts, service level agreements and public security statements define what the system must achieve. They set the baseline against which objectives are judged. Collect every commitment in one place, and check that none conflicts with another or with the system description the auditor will read.

Trust Services categories in scope

Security is always in scope. Availability, confidentiality, processing integrity and privacy are added only when the organization chooses them, and each addition brings its own objectives and criteria. Narrowing or widening the categories changes how many risks must be assessed, so record the decision and the reason for it before fieldwork.

Subservice organizations that contribute

Cloud hosts, payment processors and other vendors may help meet some objectives. Decide whether their controls are carved out and covered by their own reports, or included in the system and tested. Each choice moves risks into or out of the assessment, so list the vendors that touch in-scope data and confirm which objectives depend on them.

How objectives differ for operations, reporting and compliance

Operations objectives describe what the service must do for customers and how well it must do it. In a SOC 2 context, they are the statements that most directly connect to the trust services criteria in scope, such as keeping the platform available, processing customer transactions accurately, and protecting customer data while it is stored and transmitted. A clear objective names the service, the measurable condition and the boundary of the system. Management decides these objectives, and the choices it makes about service levels, supported customers and acceptable downtime define how much risk the team must assess.

Clear example: "Customer-facing API requests for the production tenant complete without unplanned outage during each business day, measured from the status monitoring system."
Weak version to avoid: "Keep the platform secure and reliable." Nothing in that sentence can be tested or assessed for risk.
Risks it exposes under CC3.2: single points of failure in the hosting design, dependence on a vendor for DNS or email delivery, and capacity limits that could stop the service during peak load.
Tolerance statements: an objective should state how much deviation management will accept, such as the duration of a tolerable outage, so the team can judge which risks exceed that tolerance.
Sub-objectives: break the service objective into component objectives for the database, authentication and deployment pipeline so each component has its own risk picture.

Confirm that each operations objective ties to a commitment in the system description and to the criteria you have chosen to include in scope.

How an assessor tests whether objectives are specific enough

An assessor testing CC3.1 is checking one chain of reasoning: the organization's objectives are written down, approved by management, consistent with the system description and the service commitments, and specific enough that the risk assessment in CC3.2 can be traced back to them. The assessor starts with the documents, not the interview. They will ask for the objectives in their written form, the date and approver of each version, and the system description they must agree with. Objectives that exist only in a leadership presentation or a sales deck do not give the assessor anything to test. Before fieldwork, confirm that the objectives your control matrix cites are the same wording that management approved and that the system description uses.

The assessor then reads the risk assessment against the objectives. Each objective should be traceable to the risks that could prevent it, and each material risk should map back to an objective it threatens. The gaps they look for are predictable: a service commitment in the contract, such as an uptime or data handling promise, with no objective behind it; an objective about customer data protection with no risk recorded against it; or a risk register that discusses vendors and incidents while the stated objectives never mention them. A gap between stated objectives and identified risks is the finding most likely to send an assessor back for more evidence. Run this comparison yourself before the auditor does, and record who reviewed it and when.

Expect the assessor to ask how objectives are kept current. Objectives change when the product, the customer base, the regulatory position or the hosting model changes, and an objective set at the start of an observation period may not reflect a mid-period change. Confirm who owns the review, what triggers an update, and how the revised objectives reach the risk assessment and the system description. Do not expect a fixed number of samples or tests to be published here: the assessor sets the extent of testing for your engagement, and the amount of evidence needed depends on how your objectives are written and changed over the period.

What the assessor asks for and where teams get findings

This table compares, for each part of the CC3.1 objectives work, how an assessor usually tests it, the evidence they request, and the findings teams most often receive. Read it as a preparation checklist: each row is a place where an objective can look sound on paper but fail when the auditor traces it back to the system and to management's decisions.

Area	Test approach and evidence requested	Common findings
Written objectives document	Assessor reads the current objectives statement and checks it covers operations, reporting and compliance objectives. Evidence: the dated, versioned document and its revision history.	Objectives are generic slogans with no measurable meaning, or the document is undated and has no owner.
Management approval and review	Assessor looks for evidence that a named executive or board committee approved the objectives and reviewed them on a set cycle. Evidence: meeting minutes, sign-off records, review tickets.	Approval exists only as an informal email, or the review cycle is documented but not actually performed in the period.
Traceability to the system description and commitments	Assessor compares each objective against the system description and the service commitments. Evidence: a mapping table linking objectives to commitments, system components and in-scope criteria.	Objectives describe security goals that the system description never mentions, or commitments to customers have no matching objective.
Risk tolerances and sub-objectives	Assessor checks whether tolerances are defined for key objectives and whether sub-objectives are set for risk assessment. Evidence: tolerance thresholds, sub-objective register, decisions when tolerances were exceeded.	Tolerances are missing, stated as vague terms such as low or acceptable, or never applied when risk assessments found exceptions.
Consideration of external laws and regulations	Assessor asks how customer contracts and applicable laws were reflected in objectives. Evidence: a list of applicable obligations with the objectives that address them.	Legal or contractual obligations are known to the business but absent from the objectives, so later risk work never picks them up.
Updates after significant change	Assessor samples changes such as new products, acquisitions or vendor shifts and checks whether objectives were revisited. Evidence: change records linked to objective reviews with dates.	Objectives remain unchanged after a major platform or organizational change, so the risk assessment in CC3.2 rests on outdated goals.

Writing objectives an auditor can trace to risks

This sequence turns broad business goals into a set of objectives, tolerances and sub-objectives that management has approved and that link cleanly to the system description. The output gives the CC3.2 risk identification work a fixed reference point an auditor can test.

Confirm the system boundary
Before writing any objective, agree which services, infrastructure, data flows, people and third parties sit inside the system under examination. Management and the CPA firm should review the draft boundary together, since objectives that reach beyond it cannot be traced to the controls the auditor tests. The output is a boundary statement that names in-scope components and the Trust Services categories selected, and that is referenced in every later step.
Draft operational, reporting and compliance objectives
Working with product, engineering, finance and legal owners, write objectives in three groups: operations (what the service must do for customers), reporting (what internal and external information must be accurate and timely) and compliance (which laws, regulations and contractual commitments apply). Each objective should be specific enough that a reviewer can say whether a risk affects it. The output is an objectives register with an owner, a source and a link to the relevant service commitment for each entry.
Set risk tolerances and sub-objectives
For each objective, state how much deviation management will accept, such as acceptable downtime, data loss or error rates, and break large objectives into measurable sub-objectives that risk assessment can use. Tolerances should reflect management's choices rather than defaults copied from a template. The output is a tolerance statement attached to the register, with each sub-objective marked with the risk area it informs.
Obtain management approval
Present the register, boundary and tolerance statement to the executives accountable for them, and record their approval with the date and the version reviewed. Approval shows that objectives were set by management and not by the people who will later be tested against them. Ask the CPA firm whether it expects a specific form of approval record. The output is a signed or minuted approval tied to a version number.
Link objectives to the system description and commitments
Cross-check each approved objective against the system description, the customer-facing service commitments and the system requirements it supports. Where an objective has no matching commitment, or a commitment has no objective behind it, resolve the gap before fieldwork. The output is a traceability table that maps objectives to description sections, commitments and the CC3.2 risk assessment entries that will address them.
Schedule review and record changes
Set a review point for the objectives register, typically tied to changes in business strategy, regulation, systems or the service boundary, and record every revision with its reason and approver. An auditor will look for evidence that objectives were reconsidered when the environment changed, and CC3.4 relies on the same trigger events. The output is a change log and a review calendar kept with the register. Confirm the review frequency your CPA firm expects before setting it.

Evidence that shows objectives exist, are approved and stay current

An auditor testing CC3.1 looks for a written set of objectives, proof that management approved them, and proof that they were revisited when the business changed. The cards below cover the artifacts that carry that proof and the habits that keep each one current between audits.

Approved objectives document

This is the core record: operations, reporting and compliance objectives written in terms specific enough that risks to them can be identified later. Check that each objective names what success looks like, who owns it, and which system or service it relates to. Vague statements such as "keep customer data safe" give a risk assessment nothing to test against. Review the document at least annually and whenever a new commitment to customers or regulators is made.

Meeting minutes and sign-off records

Approval is evidence only when it can be traced to the people who hold authority over the objectives. Keep minutes from the meeting where leadership reviewed the objectives, along with the names of the approvers and the date of each sign-off. Confirm that the approver's role is one the organization has defined as responsible for objectives, since an auditor will ask whether the person had the authority to approve them.

Risk tolerance statements

CC3.1 expects management to consider how much risk it will accept in pursuit of each objective. A tolerance statement records the acceptable variation, for example the downtime or data loss the business will tolerate before escalation. Check that each tolerance is tied to a specific objective and that the people who set it are the same people who approved the objectives. Tolerances written without a link to an objective are hard to defend in fieldwork.

Link to the system description

The objectives must match what the system description says the service commits to customers and what it covers. Maintain a cross-reference that shows which objective supports each commitment described in the system description. When the two documents diverge, the auditor will treat the gap as a control exception. Re-read both documents together before each audit period starts and after any material change to the service.

Version history of objectives

An auditor will ask what the objectives said during the examination period, not only what they say today. Keep every approved version with its effective date, the change made, and the reason for the change. Store the history in the same controlled location as the current document so that no version can be lost or overwritten. Confirm that changes are dated and attributed to a named person.

Review records after changes

Objectives should be reassessed when the business changes, such as a new product, a new regulator, an acquisition, or a new critical vendor. Record each review, even when the outcome is no change, with the date, the trigger, the reviewer and the decision. Between audits, set a recurring review calendar and keep the calendar entries and completed reviews as evidence that monitoring of the objectives continues.

What CC3.1 costs in staff time, tooling and outside review

This table lists each cost component of setting SOC 2 objectives under CC3.1, who is paid for it, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for a quote: most of the cost is internal leadership time, and tooling changes the price of records more than the effort of writing objectives.

Cost component	One-time or recurring	What drives it	How to keep it down
Leadership time to set objectives	One-time to draft, recurring to review	Number of service commitments, customer contract terms, and how many business lines share the system	Limit the first draft to commitments already in contracts and security questionnaires, then review on a fixed cycle
Risk tolerance and sub-objective decisions	Recurring	Number of risk tolerances management must approve and how often the business model changes	Record tolerances once in a short decision log and revisit only when scope or strategy changes
Document upkeep for objectives	Recurring	How many objective statements exist, how often they change, and how many documents repeat them	Keep one controlled source for objectives and link other policies to it rather than copying text
External facilitation or review	One-time, sometimes recurring	Whether internal staff have done objective-setting before, and whether a consultant or fractional leader runs workshops	Ask for a fixed-scope workshop and a written deliverable, and confirm who approves the final wording
Auditor sampling of objective artifacts	Recurring each examination period	The number of objectives and supporting records the auditor selects, and how traceable each objective is to risk assessment outputs	Keep versioned approvals, meeting minutes and a clear link from each objective to its risks
Tooling for records and traceability	One-time setup, recurring hosting and maintenance	Whether objectives sit in a GRC tool, a wiki or shared files, and whether licenses or self-hosting costs apply	A self-hosted open-source GRC tool can remove license spend, but the effort of writing and approving objectives remains
Staff time for evidence collection	Recurring	Frequency of approvals, number of owners who must sign off, and whether approvals are captured automatically	Assign one owner per objective and capture approvals in the tool or ticketing system as they happen

Who owns the objectives, who helps, and what the auditor checks

Management owns CC3.1. The leadership team decides what the organization is trying to achieve in operations, reporting and compliance, how much variation from those goals it will accept, and which laws and contractual commitments shape them. These choices belong to the people accountable for the service commitments made to customers, and they must be written down, approved and reviewed on a schedule the organization can explain.

Operational objectives: Service commitments, availability expectations and product goals that executives set, record and assign to named owners.
Reporting objectives: The internal and external reports the business depends on, such as customer dashboards and financial statements, and who signs off on each one.
Risk tolerance: The acceptable level of deviation from each objective, approved by an accountable executive rather than delegated silently to engineers.
Regulatory and contractual inputs: The laws and customer contracts that shape compliance objectives, reviewed with counsel or the compliance lead.
Approval record: Board or executive minutes, or a signed objectives document with dates, that the auditor can select and sample.

Before fieldwork, confirm that every objective has a named owner, an approval date and a review cadence, because the auditor will ask for all three.

Common gaps that draw findings on CC3.1

Auditors test CC3.1 by reading the objectives themselves and tracing them to the risk assessment and the system description. The gaps below are the ones that most often turn a clean-looking objective set into an exception or a weak finding. Each card names the gap and the check that closes it.

Objectives that read as slogans

Statements such as "we protect customer data" or "we are secure" cannot be measured, so no risk can be identified against them. An assessor asks what failure would look like and cannot get an answer from the text. Rewrite each objective so it names the service commitment, the population it covers and the condition that would count as a miss. For example (illustrative): "Production customer records are readable only by roles approved for support duties."

Missing reporting and compliance objectives

Many organizations write only operational objectives and leave out objectives for external reporting, such as customer-facing commitments and contract terms, and for compliance with the laws and contracts that apply to the service. CC3.1 expects these to be specified too, because they generate their own risks. Confirm that the objective set names the reporting obligations and the regulations or contractual terms that bind the service, and that each has an owner.

No stated risk tolerances

An objective without a tolerance gives risk assessors no line between an acceptable deviation and a control failure. Record how much variation management accepts for each objective, such as the outage duration or the number of unresolved access exceptions that is tolerable, and who approved that level. Tolerances also tell the monitoring work in CC4 what to measure. Ask whether each objective has a tolerance written next to it.

Objectives not approved by management

Objectives drafted by the security team and never signed by management are a common finding, because CC3.1 relies on management choosing the objectives. Keep a dated approval record from an accountable executive, with the version of the objective set it covers. Re-approve after material changes. Ask who signed the current set and when, and whether that person had authority over the business lines the objectives affect.

Objectives not tied to the system boundary

Objectives written for the company as a whole often do not say which system, services, data and infrastructure they cover. An assessor then cannot tell whether a risk to the in-scope service is covered. Define the boundary first, then state each objective against it, including subservice organizations whose operation affects the commitments. Check that every in-scope component appears under at least one objective.

Objectives never revisited after change

Objectives set at the first audit often go stale after a new product, acquisition, cloud migration or change in customer contracts. When the objectives do not move with those changes, the risk assessment in CC3.2 and the changes assessed in CC3.4 are built on the wrong targets. Set a review trigger for material changes and an annual review, and keep the history of revisions so the auditor can see when each objective changed and why.

Questions teams ask about CC3.1 before an audit

How much effort does writing SOC 2 objectives take?

The effort depends less on the wording than on how many objectives the organization already has written down. Teams that already keep a mission statement, product commitments, customer contract terms and a list of applicable laws usually need to consolidate and test those statements rather than invent them. Teams starting from nothing spend most of their time agreeing on operations, reporting and compliance objectives with the people who own each one. The main drivers are the number of products and services in scope, how many customer commitments are written into contracts, how many laws and regulations apply, and whether leadership has already agreed on risk tolerances. Ask any consultant to show how they will turn those inputs into a traceable objectives list before you agree on a price.

Can a small team write SOC 2 objectives without outside help?

Yes, a small team can write its own objectives if one person holds enough authority to make decisions and the company's commitments are easy to find. The work is mostly documentation and agreement, not specialist engineering. Outside help becomes useful when the founders are too close to the product to see gaps, when customer contracts contain security commitments nobody has tracked, or when the team has no one who has read a SOC 2 criteria set before. A consultant can review the draft and challenge it, but the objectives must reflect what the organization actually intends to do, so the owner of the system should sign them off.

How long does it take to prepare CC3.1 evidence for an auditor?

Evidence for CC3.1 is usually a set of approved, dated documents rather than system logs, so the preparation time is driven by approval cycles and version control. The auditor will typically want to see the objectives, who approved them, when they were last reviewed and how they connect to the risk assessment. Time is lost when objectives exist only in slide decks, chat threads or individual memories, or when different documents state different commitments. Confirm with your auditor which documents and approval records they expect, and set an internal date for when the objectives must be stable before the examination period starts.

What does CC3.1 require from leadership?

CC3.1 requires leadership to make visible choices about what the organization is trying to achieve and how much risk it will accept in pursuing those goals. Executives need to approve the operations, reporting and compliance objectives, agree on risk tolerances, and confirm that external laws and contractual obligations are reflected. Without that approval, the risk assessment under CC3.2 has nothing reliable to measure against. Leadership time is usually a few structured review sessions rather than a continuous commitment, but the decisions must be documented and attributed to named roles.

Can the auditor write our SOC 2 objectives for us?

No. An independent CPA firm examines and tests the objectives, but it cannot set them, because the organization owns its control environment and its management's assertion. Auditors may explain what the criteria expect and point out gaps, and some firms offer readiness services, but writing the objectives is management's responsibility. Preparation services from an implementation partner can help draft and organize the documents, and the organization still has to review, adopt and maintain them. Ask your CPA firm in writing which parts of the preparation work it will perform and which it will not, since independence rules shape the answer.

How do CC3.1 objectives affect Type 2 testing?

In a Type 2 examination, the auditor tests whether controls operated effectively across an observation period, so objectives that change during that period create questions. If the organization revises its objectives, risk tolerances or commitments mid-period, the auditor will want to see when the change happened, who approved it and how the risk assessment was updated. Clear, versioned objectives make these checks straightforward. Vague or unrecorded changes can lead to exceptions in the report. Plan a review cadence before the period opens, and record every revision with a date and approver.

How DeployOpen prepares objectives and evidence for CC3.1

DeployOpen's part in CC3.1 is preparation. Before any work starts, the scope is agreed in writing, and that document states which services, environments and trust services categories the objectives must cover. From there, DeployOpen prepares an objectives register for management to review, edit and approve. Each entry records the objective, its type (operations, external or internal reporting, or compliance), the external laws or contractual commitments it reflects, the tolerance management has set for disruption or error, and the sub-objectives that risk assessment will use. The register is a draft until management signs it, and the organization owns the wording of its own objectives.

Traceability is the part auditors test most directly. DeployOpen links each objective to the system components, the owners named in the organization's governance records and the controls that serve it, so an examiner can follow a line from an objective to the evidence that the control operated. Where the register later feeds the CC3.2 risk identification work, the same identifiers carry through. Illustrative example: an objective to keep customer data available within a stated tolerance would point to the backup and recovery records and the owner who approved that tolerance. Confirm with your CPA firm which form of traceability and which evidence format it expects before the register is finalized.

DeployOpen does not issue SOC 2 reports, attestations or certifications. The examination is performed by an independent CPA firm under the AICPA attestation standards, and that firm decides whether the objectives and evidence are sufficient. Handover consists of the approved register, the traceability map, the evidence folder structure and a short record of decisions taken during preparation, so management can maintain them between audits. Ask any implementation partner to state in the scope which artifacts it delivers, who approves them and what remains for management to own after handover.

CC3.1 Specifying objectives