- Data privacy is now a multi-jurisdiction compliance problem: GDPR in the EU, CCPA/CPRA in California, and dozens of state-level privacy laws across the US create complex documentation requirements.
- Two focused products: Data Privacy Program (DPP) for privacy programs, Secure Engineering & Data Privacy (SEDP) for engineering integration.
- The DPP addresses the GDPR, CCPA, HIPAA, FERPA, and state-level privacy laws in a unified documentation set.
- The SbD/PbD addresses engineering-side controls: embedding security and privacy requirements into the SDLC from the earliest design stages.
- Both products pair well with the CDPP/SCRP for organizations building comprehensive privacy and engineering programs.
Privacy & Secure Engineering Documentation
When you "peel back the onion" and prepare for an audit, there is a need to address "the how" for certain topics, such as how Security by Design (SbD) and Privacy by Design (PbD) principles are managed. While policies and standards are designed to describe WHY something is required and WHAT needs to be done, many companies fail to create documentation to address HOW the policies and standards are actually implemented. We did the heavy lifting and created a program-level document to address this need and the Secure Engineering & Data Privacy (SEDP) is that solution.
Privacy program documentation addresses the organization's handling of personal data across its lifecycle, from collection through retention and disposal. With GDPR, CCPA/CPRA, state-level laws, and sector-specific regulations like HIPAA and FERPA, a robust privacy program is now table-stakes for most organizations.
Secure engineering documentation addresses the other side of the coin: how security and privacy requirements are embedded into the software development lifecycle, product design, and architecture decisions. This is the "shift-left" discipline of ensuring that products and systems are designed with security and privacy as first-class requirements.
Managing Data Privacy & Cybersecurity Principles Does Not Have To Be Hard
If you can use Microsoft Word and Excel, then you can perform both Security by Design (SbD) and Privacy by Design (PbD) by simply following the instructions and editing the template to suit your specific requirements. While this is a template, we did the hard work of creating the formatting, bringing together the correct scope of information that needs to be addressed!
Operationalize Security by Design (O-SbD)
Security by Design (SbD) requirements come from numerous sources. In this context, the most important are:
- International Organization for Standardization (ISO)
- National Institute for Standards & Technology (NIST)
- US Government (HIPAA & FedRAMP)
- Information Systems Audit and Control Association (ISACA)
- Cloud Security Alliance (CSA)
- Center for Internet Security (CIS)
- Open Web Application Security Project (OWASP)
Operationalize Security by Design (O-SbD)
Privacy by Design (PbD) requirements come from numerous sources. In this context, the most important are:
- Fair Information Practice Principles (FIPPs)
- European Union (EU) General Data Protection Regulation (GDPR)
- Organization for the Advancement of Structured Information Standards (OASIS)
- International Organization for Standardization (ISO)
- National Institute for Standards & Technology (NIST)
- Information Systems Audit and Control Association (ISACA)
- US Government (HIPAA & FTC Act)
Available Privacy & Secure Engineering Products
Two focused products. Purchase individually or combine for comprehensive privacy-and-engineering documentation coverage.
Comprehensive Coverage
Give us a call or send us an email - we are happy to help you find the right solution for your needs!
There are a lot of choices to pick from when selecting a cybersecurity framework. If you are not sure what works best for you, you can read more here. The most common frameworks are NIST 800-53, ISO 27002, the NIST Cybersecurity Framework and the Secure Controls Framework (SCF). To do NIST CSF, ISO 27002 or NIST SP 800-53 properly, it takes more than just a set of policies and standards. While those are foundational to building a cybersecurity program aligned with that framework, there is a need for program-specific guidance that helps operationalize those policies and standards (e.g., risk management program, third-party management, vulnerability management, etc.). It is important to understand what is required to comply with NIST CSF vs ISO 27002 vs NIST SP 800-53, since there are significantly different levels of expectation.
It is important to understand that picking a cybersecurity framework is more of a business decision and less of a technical decision. Realistically, the process of selecting a cybersecurity framework must be driven by a fundamental understanding of what your organization needs to comply with from a statutory, regulatory and contractual perspective, since that understanding establishes the minimum set of requirements necessary to:
- Not be considered negligent with reasonable expectations for cybersecurity & data protection;
- Comply with applicable laws, regulations and contractual obligations; and
- Implement the proper controls to secure your systems, applications and processes from reasonable threats, based on your specific business case and industry practices.
This understanding makes it easy to determine where on the "framework spectrum" (shown above) you need to focus for selecting a set of cybersecurity principles to follow. This process generally leads to selecting the NIST Cybersecurity Framework, ISO 27002, NIST SP 800-53 or SCF as a starting point.