Compliance & Policy (BSIMM6 Part 3)

“Surround yourself with the best people you can find, delegate authority, and don't interfere as long as the policy you've decided upon is being carried out.” – Ronald Reagan


The Compliance & Policy practice is the second practice of the BSIMM6 Governance domain. The goal of this practice is to have prescriptive guidance for security requirements and compliance objectives for all Secure Software Development Life-Cycle (SSDL) stakeholders. It describes activities such as identifying compliance and Personally Identifiable Information (PII) requirements and the creation of a software security policy that covers the SSDL related activities. More information about the Compliance & Policy practice can be found here. The full BSIMM6 is available under the creative commons and can be downloaded at

Practice: Compliance & Policy

The governance domain contains practices that help organize, manage, and measure a software security initiative. Compliance & Policy, the second of three practices in the governance domain aims at identifying controls for compliance requirements that address the regulations a company is exposed to, including developing contractual controls, setting an organizational software security policy, and auditing against that policy.

In the first part of this blog series it was established that BSIMM6 activities are categorized in maturity levels ranging from low maturity (level 1) to high maturity (level 3). This article focuses on the foundational activities (maturity level 1), however if you want to learn more about the activities in maturity level 2 and 3 visit the Compliance & Policy section at the official BSIMM6 website.

Unify regulatory pressures

The Software Security Group (SSG) acts as focal point for unifying regulatory requirements such as PCI DSS or MAS TRM and understanding how they translate to software. By removing redundancies from overlapping requirements it can be ensured that compliance work is completed as efficiently as possible. These unified regulatory requirements are captured in the software security guidance document that demonstrates how the organisation complies.

Identify PII obligations

Out of all activities in this Compliance & Policy practice, this one has been observed in most organizations.
If you are not doing this activity yet, then it is a good place to start.

The SSG supports the process of identifying and describing PII obligations that are imposed from regulation and customer expectations. Based on these obligations the software security guidance is updated to promote best practices related to privacy and the handling of PII.

Create policy

A software security policy describes all organizational security requirements including those to comply to regulations. Through the policy, security requirements are clearly defined and can be easily consumed by project teams. Even though the policy doesn't contain architecture standards or coding guidelines, the policy mandates their use.

Start. Stop. Continue.

Consider the following strategy:

  • Start: Creating a software security policy.
  • Stop: Leaving the implementation of security requirements up to chance.
  • Continue: Centralising your security and regulatory requirements.

How does your software security initiative compare with your industry peers? Contact us to find out.