This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "SAMM - Policy & Compliance - 1"
m |
David Fern (talk | contribs) |
||
Line 57: | Line 57: | ||
---- | ---- | ||
===Additional Resources=== | ===Additional Resources=== | ||
− | + | [[:Category:SAMM-PC-1]] | |
</div> | </div> | ||
Line 63: | Line 63: | ||
__NOTOC__ __NOEDITSECTION__ | __NOTOC__ __NOEDITSECTION__ | ||
+ | [[Category:SAMM-PC-1]] |
Latest revision as of 00:39, 20 April 2015
![]() |
For the latest project news and information, join the mailing list and visit the OpenSAMM website. |
Policy & Compliance - 1
Objective: Understand relevant governance and compliance drivers to the organization |
Results
- 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
Costs
- Initial creation and ongoing maintenance of compliance checklist
Personnel
- Architects (1 day/yr)
- Managers (2 days/yr)
- Business Owners (1-2 days/yr)
Related Levels
- Strategy & Metrics - 1
Activities
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.