Security policy document examples for B2B SaaS apps

If you’ve been put in charge of writing a security policy document, you might feel a tad overwhelmed. The trick is not to overload your customer with information, but to be candid about how their data is managed and protected.

Just take a glance at the table of contents to Slack’s National Cyber Security Centre (NCSC) doc. Or, we should say, the first of three pages of contents.

Overwhelming is right. That’s why we scrutinized documents published by Slack, Stripe, Google, and Dropbox to learn what a security policy for a B2B SaaS app should include.

Four topics every security policy document for a B2B SaaS app needs

Minimally, a security policy document should cover what you do — through white papers, certifications, technical walkthroughs — and why you do it — in four areas:

• Authentication — Ensure the user is who they say they are before you give them access to data.
• Data security — Keep data out of the hands of hackers with modern encryption and network security.
• Risk management — Identify vulnerabilities and form an action plan in case of a breach.
• Compliance — Display third-party certifications, such as SOC II, and explain how you comply with federal regulations.

By addressing these four topics, you can ensure your customers feel protected, informed, and taken care of.

How Slack documents authentication

Basic app security means ensuring that a user is who they say they are. Identity verification and authentication have a long history in computer science. These days, authentication (particularly for B2B SaaS apps) typically goes beyond username / password and into MFA (Multi-Factor Authentication) or SSO (Single Sign-On).

To understand how to talk about authentication in your security docs, we looked at how Slack did it in their identity and device management documentation.‍

List your methods for access control

Your security policy document should clearly detail the access control methods in your product. This includes management features like Enterprise Mobility Management (EMM), MFA, SSO, or forced app versioning.

Slack provides a list of their identity and device management controls that customers can use in their security datasheet.

Each bullet is a security feature that they offer to customers. Symbols next to each kind represent the availability on desktop / mobile or if the feature is provided through a third-party app. ‍

Explain how users can configure the controls

‍Slack further outlines the access control responsibilities for themselves and their customers in section 10 of their NCSC Cloud Security Principles document. While the company allows users to integrate access control methods into their product, the customer must set up the configuration.

Be clear about who’s responsible for what. Your customer may see that your product offers two-factor authentication (2FA) and assume that the integration works right out of the box. If they need to set it up themselves, explain how to do it.

Provide guides or tutorials in your help center that walk your customers through the process, like Slack does with SSO integrations and mandatory workspace 2FA. Then link to this info in your security document. Go a step further by suggesting configurations or best practices. Your customers will appreciate it.

How Stripe documents data security

Data is the bread and butter of security. Your company likely deals with some kind of personally identifiable information (PII), payment card industry (PCI) data, or protected health information (PHI), so pay special attention here.

Since Stripe handles their customers’ sensitive financial information every day, we looked at how they document data security.‍

Show how and where data is stored (data at rest)

Let’s start with “how” your data is stored. These days, there are many encryption methods for securing data at rest. While business execs may not understand the difference, developers and product managers — particularly ones with an eye for security — will want to know the gritty details. ‍

Stripe tells their customers that they use AES-256 encryption for all of their data at rest. There’s no need to go beyond that. If your customers want to know about the algorithm you chose, they can Google it.

Be explicit about your data architecture, including where you store data and what services you use, such as S3 or RDS. Don’t forget about encryption! Explain how you’re managing encryption keys, such as whether you encrypt the keys, how often you rotate them, and whether there is access control.

For example, Stripe’s security policy documentation (from above) explains that it stores encryption keys on separate servers and also restricts their internal servers from viewing plaintext card numbers.

Like Stripe, tell your customers how your infrastructure is designed: which services have access to what data, and what has restricted access.‍

Detail your data transportation protocols (data in transit)

For an application to be functional, data can’t sit snug in a secure database forever — it’s going to need to move, probably bi-directionally to the client. When writing your security policy document, your job is to tell the user what protocols are keeping their data safe in transit.‍

Stripe does more than list their protocols. They tell customers where these protocols are enforced. Plus, readers are told that the company regularly performs audits on the certificates served, certificate authorities they use, and all supported ciphers.

Finally, there’s a use case for data in transit that’s sometimes overlooked in security policy documents: data migrations. Sometimes, data needs to be ported to your application, particularly when a new customer decides to switch to your app. While data migrations are not done often, it’s still important that you provide a thorough guide to help your customers migrate their data securely.‍

Stripe provides a data migration PGP key guide in their docs for porting payment card industry (PCI) data, like credit card data. They even link out to external sources like GnuPG and instructions for how to import a public key.

How Google’s GSuite documents risk management

A large factor in security is being aware of weaknesses, vulnerabilities, and risks in the system. While no company can ever be 100% safe from an attack, there are steps you can take to mitigate the risks. G Suite shows the steps they take in their Operational Security documents. ‍

Highlight your weak spots and how you defend them

The best way to fend against an attack and protect weaknesses is to have multiple safeguards. You can’t trust just one piece of software or one audit to catch everything. Instead, be open about vulnerabilities that do (or may) exist and how to manage them.

G Suite uses a combination of practices to handle vulnerabilities, which they outline in the “Vulnerability management” section.

First, they list their processes employed to detect vulnerabilities — security threat detection tools, QA, external audits, and the like. Next, they introduce the dedicated vulnerability management team and highlight their stringent processes for finding, following, and resolving security weaknesses. Finally, G Suite provides a way for customers to report vulnerabilities they have found, and even has a reward system set up. ‍

Explain what you’re keeping watch for

While you may not be able to prevent every attack, you can build up safeguards to catch suspicious behavior as soon as possible. One way to do this: Keep careful logs and audits of network traffic, and analyze them regularly.

G Suite employs security engineers who focus just on this task and also deploy automated network log analysis to help with monitoring. In the “Monitoring” section of their Operational Security docs, they list out what’s reviewed regularly, including inbound security reports, public mailing lists, and blog posts.

The idea is to tell your customers how you monitor weak points and who is doing the monitoring. Knowing about vulnerabilities isn’t enough; you must be actively looking for new ones. Automated monitoring tools are especially great to document, as they can often spot problems that a manual search may overlook.‍

Share your security breach action plan

So now that your security policy document has identified vulnerabilities and outlined how they are monitored, you need to tell your customer what you’ll do if an incident does happen. Establishing a protocol, identifying who does what in various scenarios, keeps people calm, establishes trust, and gives everyone a feeling of, “Hey, we got this.”

Google employees can contact a security team available 24/7 in case of an incident. The security team logs, triages, and works to resolve all security problems. The security team also has rules about mitigating incidents and documenting what happened.

Additionally, G Suite’s security policy documentation includes information about how they test their action plans, which help their security engineers stay prepared for whatever incident may occur.

How Dropbox documents compliance

Technology often moves so fast that the law can't keep up. In fact, it’s only in recent years that laws encompassing data security and privacy have started to emerge in full force. While your company might not specifically need compliance with some of these laws, it might be non-negotiable for your customers’ customers. Plus, anyone who’s worried about security and looking into your product will know what to look for and be pleased to see your security certifications.

To help you incorporate legal compliance into your security policy document, we reviewed Dropbox’s documentation. They have all compliance-related material located on one page, with links to better understand various standards, regulations, and certifications.

List your standards, regulations, and certifications

Companies can get numerous standards, regulations, and certifications around compliance. Some are offered by third-party auditors, and some are outlined by the federal government. If you don’t want to get into the details about each item in your security policy document, link out to relevant information so your customers can read up.

If any of the following standards, regulations, and certifications might be relevant to your customers, include them in your documentation: ISO Certification (Clearly state the particular ISO certification, not just “ISO certified”); (SOC) 1, 2, and 3; CSA STAR; EU-U.S. Privacy Shield and Swiss-U.S. Privacy Shield; FINRA; HIPAA/HITECH; GDPR; PCI DSS; FERPA; and COPPA.

Dropbox lists a high-level version of their compliance on their security landing page, but readers who want to get into the weeds can visit their standards and regulations page. This page goes into detail about each standard, regulation, and certification they possess. Readers can even download and view certificates, like this one for ISO/IEC 27001:2013.

Whenever you can, provide links to certificates and reports as an extra layer of transparency to your customers. Or, if you can’t link to your documents, provide a contact form for customers to ask a sales engineer or technical lead any questions they might have.

The best security policy documents are transparent

Remember, your customers want to feel protected, informed, and taken care of. Be abundantly clear on how you are doing so. Companies like Slack, Stripe, Google, and Dropbox are transparent with their customers in their security policy documents. This helps their customers focus on building incredible things instead of worrying about a breach.‍

Inform your customers in great detail exactly how you are protecting their data in your application. Take care of them when they ask questions, find issues, or request changes. Empower your customers to do great things with your technology by giving them a transparent security policy document.