Most DPA security traps don’t start with bad intentions. A founder needs a DPA, finds a template from a well-known SaaS company, copies the security schedule, and moves on. The problem is that template was written to reflect the security posture of a company with a dedicated security team, an annual penetration testing program, and infrastructure built for enterprise scale. You are not that company yet. Your DPA shouldn’t pretend otherwise.
Security commitments in a DPA are legally binding. If your Schedule B says “AES-256 encryption at rest managed by a dedicated security team” and you’re running on a managed cloud platform with default encryption and no security hire, you’ve created a contractual obligation you cannot fulfill. When a breach occurs, and for enough companies it eventually does, the gap between your stated security posture and your actual one becomes exhibit A in your customer’s claim against you.
The fix is not weaker security. It’s accurate documentation.
The Infrastructure Provider Boundary
The first thing to understand about your security posture is that most of it isn’t yours. It belongs to your infrastructure provider.
If you’re running on AWS, GCP, or Azure, those platforms handle a significant portion of what enterprise security questionnaires ask about: physical data center security, hardware redundancy, network-level DDoS protection, hypervisor isolation, and much of the encryption infrastructure. This is the shared responsibility model, and it matters enormously for how you describe your security measures.
What your infrastructure provider handles, you can reference, but you cannot claim as your own implementation. The correct framing is: “physical and environmental security is managed by [AWS/GCP/Azure] in accordance with their published security standards and certifications, including SOC 2 Type 2 and ISO 27001.” You are not implementing those controls. You are inheriting them by virtue of using that platform.
What you actually control: application-level security, access management, your own encryption key handling (if applicable), logging and monitoring configurations, deployment practices, and the security of the code you write. These are the commitments that need to reflect your actual practices.
The practical exercise before drafting Schedule B: draw a line. Everything above the line is your infrastructure provider’s responsibility. Everything below the line is yours. Only document what’s below the line as your own commitment, and only commit to what you’ve actually implemented.
What Minimum Viable Security Commitments Look Like
There is a meaningful difference between commitments that are accurate for an early-stage B2B SaaS company and commitments that are either inadequate for enterprise buyers or aspirationally false.
The following is a reasonable baseline for a seed-to-Series A company running on a major cloud platform, with a small engineering team and no dedicated security staff:
Encryption: Personal data encrypted in transit using TLS 1.2 or higher. Personal data encrypted at rest using industry-standard encryption provided by the hosting infrastructure.
Access controls: Access to production systems and customer data restricted to personnel who require it to perform their job functions. Access reviewed periodically and revoked promptly upon role change or departure. For multi-tenant architectures, row-level security enforced at the database layer to ensure tenant data isolation, meaning no customer can access another customer’s data regardless of application-level controls.
Authentication: Multi-factor authentication required for access to production infrastructure and administrative systems.
Vulnerability management: Security patches applied to infrastructure and dependencies on a regular basis. Critical patches applied within a defined remediation window.
Incident response: A documented incident response process covering identification, containment, investigation, notification, and post-incident review.
Subprocessor security: Sub-processors bound by data protection obligations and selected based on their ability to maintain appropriate security standards.
Notice what’s not on this list: dedicated security team, annual penetration testing, 24/7 security monitoring, red team exercises, formal ISMS. If you have these, include them. If you don’t, don’t.
The goal is a Schedule B that a reasonable enterprise buyer accepts as adequate for your stage, while remaining entirely accurate. Most enterprise procurement teams understand that early-stage vendors won’t have the security apparatus of a Fortune 500 company. What they cannot accept is discovering that your documented commitments don’t match your actual practices.
Penetration Testing: The Commitment Founders Get Wrong
Penetration testing is one of the most commonly misrepresented security commitments in startup DPAs. Templates often include language like “annual penetration testing conducted by a qualified third party.” If you’ve never commissioned a penetration test, this is a false statement.
If you do conduct penetration testing, the commitment needs to be precise: who conducts it (internal, third-party, or both), how often, what scope (application layer, infrastructure, or both), and what you do with the results. “Annual penetration testing” without scope or remediation obligations is meaningless and may still misrepresent your actual practices.
If you don’t yet have a penetration testing program, the honest commitment is silence on the topic, or a forward-looking statement scoped to what you’ve actually implemented: “We conduct security testing of our application prior to major releases.” That’s accurate if it’s true, and says nothing you can’t defend.
The business implication: if a customer’s security questionnaire requires annual third-party penetration testing and you don’t have it, that’s a gap to close operationally, not a gap to paper over contractually. Contracting your way past a security requirement you don’t meet is how you end up with liability exposure that a pen test would have cost far less to avoid.
Schedule B as a Living Document
Security posture changes. You hire a security engineer. You add MFA. You complete your first SOC 2 audit. You move from one cloud provider to another. Your DPA’s Schedule B needs to reflect this.
The mistake is treating Schedule B as static boilerplate. It should be a versioned document with a last-reviewed date, updated whenever your actual security practices materially change. Your customer DPA should include a mechanism for updating Schedule B: notice to customers, a reasonable review period, and a clear statement that updated measures must maintain at least the same level of protection as prior measures.
This structure serves two purposes. It keeps your commitments accurate over time without requiring full DPA renegotiation every time your security posture improves. And it creates a documented record that your security program is active and evolving, which is itself a signal enterprise buyers value.
The practical implementation: maintain Schedule B as a separate document referenced by your DPA, not embedded inline. Version it. Date it. Review it at least annually and after any material infrastructure change.
The SOC 2 Connection
SOC 2 certification and your DPA security schedule are not independent. They’re two expressions of the same underlying security program, and they need to be consistent.
Your SOC 2 report describes the controls you’ve implemented and whether they operated effectively during the audit period. Your DPA security schedule describes the measures you commit to maintaining for customers. If your DPA promises controls that aren’t reflected in your SOC 2 scope, you’ve either over-committed in your DPA or under-scoped your audit. Either creates a problem.
The right sequencing for most founders: document your actual security posture in Schedule B first, then use that documentation as the basis for scoping your SOC 2 audit. Your audit report then becomes the independent verification of the commitments you’ve already made contractually. When a customer asks for evidence that you’re honoring your DPA security commitments, you hand them your SOC 2 Type 2 report.
For more on the relationship between your contractual stack and SOC 2 certification, see No SOC 2, No Deal: Why Enterprise Sales Die Before They Start.
What Happens When You’ve Already Over-Committed
If you’re reading this having already issued DPAs with security commitments you can’t fully substantiate, you have a few options, none of them consequence-free.
The cleanest path is to close the gap operationally. Identify the commitments you’ve made that don’t reflect current practice, prioritize the ones most likely to matter in a breach scenario, and implement them. This is also the right thing to do regardless of contractual exposure.
For commitments that are genuinely aspirational rather than false, meaning you have the capability but haven’t formally documented the process, document it now. An incident response plan that exists in practice but hasn’t been written down is a gap you can close this week.
For future customers, update your Schedule B to reflect your actual posture before issuing new DPAs. The goal is not to weaken your security commitments. It’s to make them accurate, so that your contractual obligations and your operational reality are the same document.
No Boiler provides self-service legal document generation and educational content. This material and our service is not a substitute for legal advice. Please have a qualified attorney review any documents before relying on them. No Boiler is not a law firm, and communications with us do not create an attorney-client relationship or carry any expectation of confidentiality. Use of our platform and content is governed by our Terms of Service and Privacy Policy.