The information customers need to use a service safely
A customer enables a new integration and assumes the service provider monitors every administrative action performed through it. The provider assumes the customer reviews those actions. Neither team discovers the difference until someone investigates an unexpected configuration change.
Both organizations may have capable people and functioning controls. Their working assumptions still leave a gap.
Under the AICPA Trust Services Criteria, CC2.3 concerns communication with external parties about matters that affect internal control. Information needs to travel in both directions. Customers and suppliers need usable instructions, while management needs to hear about problems those parties discover.
For a service provider, useful communication helps customers understand their responsibilities, gives suppliers a reliable contact, and ensures incoming concerns reach someone who can respond. This article in our SOC 2 Guide considers how to make those exchanges dependable. All company examples below are hypothetical.
CC2.2 addresses communication within the organization. CC2.3 follows the information across its boundary, including relevant exchanges with customers, suppliers, auditors, regulators, and other stakeholders. A clear external message still depends on the internal team knowing who can approve it and act on the response.
Start where responsibilities meet
Look at the points where your service depends on action by someone outside the organization. These may include customer account administration, supplier incident notification, outsourced support, or a partner's access to information.
Explain what the service does, where its boundaries lie, and the relevant objectives external users rely on. When confidentiality or privacy is in scope, communicate the relevant protection objectives and changes to the parties whose work depends on them.
For each relationship, identify the practical information needed on both sides. A customer administrator may need instructions for removing departed users. A hosting provider may need a current emergency contact. Your support team may need enough information to distinguish a routine question from a security concern.
Document the responsibilities in places the intended audience actually uses, such as onboarding material, service documentation, agreements, or support instructions. Check that those materials agree. A sales answer, an old implementation guide, and the current service agreement can otherwise describe three different arrangements.
In the integration example, explain who reviews administrative activity and how the customer can obtain the relevant records. Have someone unfamiliar with the integration follow the instructions. If they cannot locate the information or understand the division of work, revise it before relying on the handoff.
Give incoming reports an owner
A published support address needs an operating process behind it. Assign coverage, define routing, and explain how staff should handle urgent or sensitive reports. Consider what happens outside normal working hours and when the primary contact is away.
Customers should be able to find the appropriate way to report a suspected service problem. Technical researchers may need a route for reporting a vulnerability without placing sensitive details in an ordinary support conversation. Suppliers need to know whom to contact when an event may affect your service.
Provide an alternative when the usual channel is ineffective or the concern involves the person who normally receives reports. Explain confidentiality honestly and route sensitive concerns to someone with appropriate authority. A second address that forwards to the same unavailable person does not solve the problem.
Test these routes periodically using a clearly identified test message. Confirm that it reaches the intended recipient and receives the expected handling. A mailbox that accepts messages but has no active owner can create a misleading impression of coverage.
Record actual reports, their assessment, and the resulting action. Relevant findings from an external assessment should reach management and the board or other appropriate governing body, rather than remaining in the project team's files. Limit sensitive details to authorized recipients.
Plan for difficult communications
Some messages need decisions before anyone sends them. A service incident may involve uncertainty about impact, competing contractual deadlines, and incomplete technical facts. Define who approves customer notices and who checks the relevant agreements and legal requirements.
Prepare a practical workflow that records the decision, approver, audience, method, and timing. Distinguish confirmed facts from matters still under investigation. If an earlier message becomes inaccurate, use the approved process to correct it and retain the history.
Choose a channel appropriate to the audience and urgency. A public status page can help communicate a broad service interruption. A confidential issue affecting one customer may need direct communication through a verified contact. Avoid placing customer-specific details in public updates.
Do not invent a universal notification deadline for every event. Applicable duties depend on the agreements, facts, and relevant law. Have qualified advisers evaluate those obligations and incorporate the resulting requirements into the response process.
A five person company with two founders
A bootstrapped software company has two founders and three staff members. The technical founder owns service operations, while the other founder manages customer relationships. One staff member handles most support requests.
The company could maintain a short customer setup guide describing account administration, supported data uses, and where to report problems. Both founders review it against the way the service actually operates. The support employee checks whether a new customer can follow it without additional explanations.
They establish a monitored support address and a separate route for sensitive security reports. The founders arrange backup coverage so a message does not remain unread when the support employee is absent. An initial test verifies that each route reaches the right person.
Suppose a customer reports access that appears inappropriate. The support employee records the report and alerts the technical founder, who assesses the facts. The other founder checks the customer contact and communication obligations. They record what was communicated and why, while protecting investigation details.
If the company already uses Vanta, the founders could store dated customer guidance and reporting-channel test records in its Documents area, with an owner responsible for keeping the evidence current. The support ticket remains the working record of the customer issue. They should preserve actual communication dates and restrict sensitive material rather than treating an upload as proof that a customer received it.
Possible supporting evidence: customer guidance versions, verified contacts, reporting instructions, routing tests, actual tickets, approved notices, and follow-up. A shared tool can support the process if access restrictions and coverage remain suitable for the risks.
Coordinating communication in a hundred person company
A 100-person service provider has dedicated customer success, security, engineering, and procurement teams. Different departments may communicate with the same customer or supplier, making ownership and consistency more difficult.
The company could assign owners to its standard security responses, implementation guides, incident communications, and supplier contact records. Changes in service design trigger review of the affected material. Customer success receives approved explanations before discussing the change with customers.
Consider a migration that changes how customers export their records. Engineering explains the technical steps; customer success identifies affected administrators; security reviews the proposed access instructions. The team records the notice sent, its recipients, and unresolved customer questions before the migration proceeds.
Procurement also maintains an escalation contact for critical suppliers. When a supplier sends a material service warning, the receiving team creates a tracked issue and routes it to the service owner. Important messages should remain visible even when the original recipient leaves the company.
A Vanta Trust Center could give customers a consistent place to request approved security documents. The team would configure document visibility and access requirements, check that the material matches current operations, and direct customers to the appropriate reporting contact. Feature availability depends on the plan. An updated portal does not replace a direct notice required by an agreement or needed for a time-sensitive change.
Possible supporting evidence: approved guidance, publication history, relevant customer and supplier populations, notices, delivery failures, support escalations, and decisions about unresolved issues. Retain the version each affected audience received when that distinction matters.
Reaching the right audience across a thousand person company
A 1,000-person company operates several services across regions. Its central communication framework identifies decision authority, while service owners maintain the customer-specific details needed to act.
During a significant outage, the incident team could prepare a common factual summary. Regional and account teams use it to notify the appropriate contacts through approved channels, taking account of different agreements and language needs. One owner reconciles the audiences so an important customer is not missed because two teams assumed the other would contact it.
The company records significant updates and corrections, including the basis for decisions made while facts were incomplete. Following the incident, reviewers examine whether recipients received useful information in time and whether incoming questions reached the response team.
Supplier communication deserves similar attention. A critical subcontractor may support several services, so an alert received by one business unit needs to reach the others that depend on it. Designate an owner for that coordination.
For the examination, the compliance team could organize communication evidence and auditor follow-up in Vanta's audit workspace. It checks that the intended auditor can see the completed evidence and uses the engagement's evidence comments for clarifications, rather than assuming an internal note is visible externally. Management still decides what may be disclosed and confirms that significant findings reach the right leaders.
Possible supporting evidence: communication responsibilities, service and regional contact records, approved messages, recipient and delivery records, supplier alerts, and post-incident actions. Protect detailed case files while providing leadership with the information needed for oversight.
What evidence should show during the period
For a SOC 2 Type 2 examination, retain records of relevant activity throughout the examination period.
A current website screenshot can show the reporting instructions available today. Historical publication records and dated tests help explain whether the process was available earlier. Actual tickets and notices show what happened when someone used it.
Retain delivery failures and how they were resolved. A message marked as sent may still have gone to a former employee or an unmonitored mailbox. Review contact accuracy as relationships change, especially for time-sensitive notifications.
Where no reportable events occurred, maintain the evidence appropriate to the controls that did operate, such as channel checks or contact reviews. Do not create fictional incidents. The auditor determines the evidence and testing needed for the engagement.
Use a relationship to test the process
Choose one customer and one critical supplier. Confirm that both sides know their responsibilities and can reach the right person when a problem arises. Review an actual recent exchange for unanswered questions or conflicting instructions.
The appropriate solution depends on service complexity, data sensitivity, and contractual obligations. A small company with sensitive customer relationships may need more formal communication than a larger company providing a simpler service. Headcount is only one consideration.
These examples are possible control designs, not prescribed SOC 2 controls. Choose review intervals, escalation arrangements, and tools around the actual risks. Vanta is one way to support the records and exchanges described here; it is not required and does not replace management judgment.
Genius GRC helps organizations develop practical SOC 2 controls and organize supporting evidence. Schedule a free consultation to work through the communication responsibilities and evidence that fit your service.
Explore the SOC 2 Guide for the full series. Next is CC3.1, Specifying Suitable Objectives.
This article provides general guidance. Evaluate the examples with your advisers and auditor in the context of your examination scope and obligations.