[CP1.3: 76] Create policy.
The SSG guides the rest of the organization by creating or contributing to software security policy that satisfies internal, regulatory, and customer-driven security requirements. This policy includes a unified approach for satisfying the (potentially lengthy) list of security drivers at the governance level. As a result, project teams can avoid keeping up with the details involved in complying with all applicable regulations or other mandates. Likewise, project teams won’t need to relearn customer security requirements on their own. SSG policy statements can sometimes focus on major compliance topics, such as handling PII or using cryptography. In some cases, policy will relate directly to the SSDL and its use in the firm. Because they might be new topics, codifying decisions about IoT, cloud, and mobile architectures can rekindle interest in setting policy. Similarly, it can be necessary, for example, to explain what can and can’t be automated into CI/CD and continuous deployment pipelines (see [SM3.4 Integrate software-defined lifecycle governance]). Architecture standards and coding guidelines aren’t examples of policy, but policy that prescribes and mandates the use of coding guidelines and architecture standards for certain software categories falls under the umbrella. Policy is what is permitted and denied at the initiative level; if it’s not mandatory, it’s not policy. In many cases, policy statements must be translatable into automation for use in a software-defined lifecycle, not just a process enforced by humans, but even automated policy must be mandatory.