A customer's questionnaire asks how you control badge access to your data center. You do not have a data center. The next question asks how you ensure only authorized users access their account, and the honest answer is that their administrators decide who those users are. Both questions are reasonable, and both are about controls someone other than you operates.
Shared responsibility is the plain fact that security for a SaaS product is split between three parties: your cloud provider, you, and your customer. Buyers know this in principle. What they need from you is the specific split for your product, written down, consistent with your audit report, and explained without sounding like you are dodging the question. This article covers how to write that split and how to use it in reviews.
The three layers
Each party operates a different set of controls.
Your cloud provider operates the physical data centers, the hardware, the network underneath your environment, and the internals of any managed services you use. You rely on those controls and cannot inspect them directly. You can read the provider's own audit reports.
You operate everything you build and configure: the application, the way you configure the cloud services, your own staff's access, your development process, backups, monitoring, and incident response for the service.
Your customer operates what they control inside your product: who their users are, what roles those users hold, how they authenticate, what data they put into the service, which integrations they enable, and the devices their staff use to sign in.
Other vendors sit in the picture too. Your email delivery provider, your support tooling, and your error monitoring service may all touch customer data. For questionnaire purposes they usually fall under your responsibility: you chose them, you configure them, and you manage the risk they bring. Say so, rather than presenting them as a separate party the customer must assess.
The split varies by product. A product that lets customers bring their own encryption keys moves part of key management to them. A product with no integrations has no integration responsibilities to assign. Write the split for your product, not a generic one.
Writing a responsibility matrix
A matrix is the clearest way to show the split. Keep it to the areas buyers ask about, and phrase each cell as an action someone takes.
| Area | Cloud provider | Your company | Customer |
|---|---|---|---|
| Physical security | Operates data center controls | Reviews provider's audit reports | None |
| Infrastructure | Maintains hardware and managed services | Configures and patches what it runs | None |
| Application security | None | Secure development, testing, fixes | Reports suspected issues |
| User access in the product | None | Provides roles, SSO, and MFA options | Manages its own users and roles |
| Authentication | None | Enforces session and password rules | Configures SSO and its own MFA policy |
| Data entered | Stores it durably | Encrypts, backs up, and restricts staff access | Decides what data to enter |
| Logs | Infrastructure logging | Application and audit logs | Reviews its own tenant audit log |
| Incidents | Handles provider incidents | Handles service incidents and notifies | Handles incidents in its own environment |
Publish a version of this on your Trust Center or include it in your standard package. What to put on a Trust Center covers where it fits among your other documents.
Keeping it consistent with your audit report
If you have a SOC 2 report, it already describes the split. The complementary user entity controls describe what customers are expected to do. The subservice organization section describes what your cloud provider and other key vendors do, and whether their controls are carved out or included.
Your matrix must agree with both. A buyer who has read how to read a SOC 2 report as a buyer will compare them. If your report lists a customer control your matrix does not mention, or assigns a control to you that the report assigns to a vendor, expect a follow-up question. Complementary user entity controls, explained covers how to write the customer side so that it reads as a clear expectation.
Answering questions that are really about someone else
Questionnaires often ask about controls you do not operate. Three rules keep those answers accurate.
Do not answer "not applicable" to an inherited control. Physical security applies to your service. You inherit it. The accurate answer says who operates the control and how you know it works: "Our infrastructure is hosted with our cloud provider, which operates physical access controls covered by its independent audit reports. We review those reports annually. We operate no data centers of our own."
Do not claim a control you do not operate. Answering "yes, badge access is reviewed quarterly" because your provider does so misstates who is doing it. If a buyer's reviewer later finds you have no office access process at all, the answer looks like an overstatement rather than a shortcut.
For customer-owned controls, say what you provide. "Customers manage their own users and roles. We support SSO through SAML and enforce MFA when the customer enables it. Administrators can review all sign-ins in the tenant audit log." That answer is accurate, and it tells the reviewer what to configure on their side.
Explaining it without sounding evasive
The risk with shared responsibility is tone. "The customer is responsible for the security of their data" is accurate in a narrow sense, and it reads as a refusal.
Pair every "that is yours" with "here is what we give you to do it." If customers own user management, point to the roles, SSO, and audit log features. If they own what data they enter, explain the data types the service is designed for and any it is not. If they own their integrations, explain how integration permissions are scoped and how to revoke them.
Consider publishing a short configuration guide: the settings a security-minded customer should turn on, with the reason for each. It turns the customer's half of the matrix into a checklist they can follow.
Where the split goes wrong
Three patterns cause most of the trouble.
The matrix falls behind the product. A new integration ships, or customers gain the ability to export data in bulk, and nobody updates the matrix. Review it whenever a feature changes who can access data.
Sales promises cross the line. An account executive says you will make sure only the right people at the customer have access. That is a customer control you cannot perform. Train the people who talk to buyers on the matrix, and give them the approved wording.
Contracts contradict the matrix. A customer's security addendum says you "shall ensure that all access to customer data is authorized." Read literally, that includes access by the customer's own users, which you do not control. The fix is usually a wording change that limits the obligation to your personnel and systems. Flag these clauses for legal when they arrive.
In regulated sectors, the split often has legal weight. A healthcare customer covered by HIPAA, for example, will want the responsibility for safeguards reflected in a business associate agreement, not only in a matrix.
How TrustLynce helps
You can publish your responsibility matrix and configuration guide on a TrustLynce Trust Center. Approved answers to shared-responsibility questions can live in the reviewed library behind questionnaire automation, so every buyer gets the same accurate description of the split.