This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Difference between revisions of "SAMM - Policy & Compliance - 1"

Jump to: navigation, search
Line 57: Line 57:
===Additional Resources===
===Additional Resources===
Line 63: Line 63:

Latest revision as of 00:39, 20 April 2015

250px-OpenSAMM_logo.png For the latest project news and information,
join the mailing list and visit the OpenSAMM website.

PC1.png PC2.png PC3.png


Policy & Compliance - 1

Objective: Understand relevant governance and compliance drivers to the organization


  • Increased assurance for handling third-party audit with positive outcome
  • Alignment of internal resources based on priority of compliance requirements
  • Timely discovery of evolving regulatory requirements that affect your organization

Success Metrics

  • >1 compliance discovery meeting in past 6 months
  • Compliance checklist completed and updated within past 6 months
  • >1 compliance review meeting with stakeholders in past 6 months


  • Initial creation and ongoing maintenance of compliance checklist


  • Architects (1 day/yr)
  • Managers (2 days/yr)
  • Business Owners (1-2 days/yr)

Related Levels

  • Strategy & Metrics - 1


A. Identify and monitor external compliance drivers

While an organization might have a wide variety of compliance requirements, this activity is specifically oriented around those that either directly or indirectly affect the way in which the organization builds or uses software and/or data. Leverage internal staff focused on compliance if available.

Based on the organization’s core business, conduct research and identify third-party regulatory standards with which compliance is required or considered an industry norm. Possibilities include the Sarbanes-Oxley Act (SOX), the Payment Card Industry Data Security Standards (PCI-DSS), the Health Insurance Portability and Accountability Act (HIPAA), etc. After reading and understanding each third-party standard, collect specific requirements related to software and data and build a consolidated list that maps each driver (third-party standard) to each of its specific requirements for security. At this stage, try to limit the amount of requirements by dropping anything considered optional or only recommended.

At a minimum, conduct research at least biannually to ensure the organization is keeping updated on changes to third-party standards. Depending upon the industry and the importance of compliance, this activity can vary in effort and personnel involvement, but should always be done explicitly.

B. Build and maintain compliance guidelines

Based upon the consolidated list of software and data-related requirements from compliance drivers, elaborate the list by creating a corresponding response statement to each requirement. Sometimes called control statements, each response should capture the concept of what the organization does to ensure the requirement is met (or to note why it does not apply).

Since typical audit practice often involves checking a control statement for sufficiency and then measuring the organization against the control statement itself, it is critical that they accurately represent actual organizational practices. Also, many requirements can be met by instituting simple, lightweight process elements to cover base-line compliance prior to evolving the organization for better assurance down the road.

Working from the consolidated list, identify major gaps to feed the future planning efforts with regard to building the assurance program. Communicate information about compliance gaps with stakeholders to ensure awareness of the risk from non-compliance.

At a minimum, update and review control statements with stakeholders at least biannually. Depending on the number of compliance drivers, it may make sense to perform updates more often.

Additional Resources