Operationalize Security by Design (SbD) & Privacy by Design (SbD)


Ready To Operationalize Privacy by Design (PbD) To Meet Compliance Needs? We are. 

At ComplianceForge, we are here to provide businesses with the documentation they need to comply with the European Union General Data Protection Regulation (EU GDPR) and other requirements that demand companies "bake in" both cybersecurity and privacy principles into their day-to-day operations and project development processes. We refer to it as Cybersecurity for Privacy by Design (C4P). 

Surprising to many people, privacy protections overlay most existing security protection mechanisms. In a C4P model, the focus is on People, Processes and Technology.



A focus on C4P allows an organization to:
    • Enable privacy principles through an integrated approach with security;
    • Preset security configuration settings so that it is secure by default;
    • “Bake in” security mechanisms, as compared to “bolting on” protections as an afterthought;
    • Keeping things simple to save resources and avoid negatively affecting users;
    • Integrate throughout the lifecycle of projects / applications / systems;
    • Support a common method to “trust but verify” for projects / applications / systems; and
    • Position security to be seen as an enabler through educating users, managing expectations, and supporting change.

Specific to the EU GDPR, there are three (3) very specific requirements that require significant coordination between privacy and cybersecurity teams to accomplish:


Most companies have requirements to document security and privacy processes, but lack the knowledge and experience to undertake such documentation efforts. That means organizations are faced to either outsource the work to expensive consultants or they ignore the requirement and hope they do not get in trouble for being non-compliant. In either situation, it is not a good place to be.

The good news is that ComplianceForge developed a comprehensive, yet realistic, security & privacy by design product. The Security & Privacy By Design (SPBD) is made up of both an editable Microsoft Word document & Microsoft Excel checklists that are based on NIST 800-160, NIST 800-37, the Generally Accepted Privacy Principles (GAPP), and the OASIS Privacy Management Reference Model and Methodology (PMRM).  This constitutes the "gold standard" for both secure engineering and privacy frameworks. Additionally, this documentation is capable of scaling for any sized company!

Please keep in mind that security & privacy engineering principles are not just limited to EU GDPR:

  • NIST 800-53 - SA-8
  • NIST Cybersecurity Framework - PR.IP-2
  • ISO 27002 - 14.2.5 & 18.1.4
  • Defense Federal Acquisition Regulations Supplement (DFARS) 252.204-7012 (NIST 800-171) - 3.13.1 & 3.13.2
  • Federal Acquisition Regulations (FAR) 52.204-21 - 4
  • National Industrial Security Program Operating Manual (NISPOM) - 8-302 & 8-311
  • SOC2 - CC3.2
  • Generally Accepted Privacy Principles (GAPP) - 4.2.3, 6.2.2, 7.2.2 & 7.2.3
  • New York State Department of Financial Service (DFS) - 23 NYCRR 500.08
  • Payment Card Industry Data Protection Standard (PCI DSS) - 2.2
  • Center for Internet Security Critical Security Controls (CIS CSC) - 1.2, 5.9, 6.2, 6.3, 6.4, 6.5, 7.1, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 8.6, 9.1, 9.2, 9.3, 9.4, 9.5, 9.6, 11.4, 11.5, 11.6, 11.7, 13.4, 13.5 & 16.5



Cybersecurity For Privacy By Design (C4P) Begins With Understanding Expectations 

Understanding the requirements for both Security by Design (SbD) and Privacy by Design (PbD) principles involves a simple process of distilling expectations. This process is all part of documenting reasonable expectations to right-size the approach, since every organization is unique:

  • Applicable best practices based on your company’s industry.
    • ISO 27002
    • NIST 800-53
    • SOC II
    • Operational Technology (OT) & Internet of Things (IoT)
  • Statutory obligations (e.g., state, federal and international laws)
    • FTC Act (prohibition on unfair business practices)
    • Family Educational Rights and Privacy Act (FERPA)
    • Children's Online Privacy Protection Act (COPPA)
    • State ID theft laws (e.g., MA 201 CMR 17)
  • Regulatory obligations (e.g., regulatory bodies or governmental agencies)
    • EU General Data Protection Regulation (EU GDPR)
    • NY Department of Financial Services (23 NYCRR 500)
  • Contractual obligations (e.g., vendor agreements)
    • DFARS / FAR (e.g., NIST 800-171)
    • Privacy Shield
    • PCI DSS


  Operationalize Security by Design (O-SbD)  


  Operationalize Privacy by Design (O-PbD)  


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)

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)

Central to Cybersecurity For Privacy By Design Requires Leveraging Common Touch Points

Unfortunately, most companies fail to see the common touch points that exist in both project lifecycles and this can lead to either gaps in coverage or duplication of efforts. Through our experience in cybersecurity and privacy, we understand these touch points and call those out to enable a "paint by numbers" approach to baking in both cybersecurity and privacy controls into development and project management processes.

This is where aligning your company’s Security by Design (SbD) efforts with the Risk Management Framework (RMF) (e.g., NIST 800-37) can be very beneficial, since the RMF provides a well-established format to securely engineer and maintain systems throughout the entire life cycle of the asset. Utilizing common linkages, Privacy by Design (PbD) is incorporated into the RMF cycle.


"Paint By Numbers" Approach To Cybersecurity & Privacy Requirements

What we've done is simply handle the heavy lifting to integrate security and privacy controls into standard project management processes. This allows your teams to have a "paint by numbers" approach to demonstrating that both cybersecurity and privacy principles are baked into the process! We identified the stages where both cybersecurity and privacy requirements are expected as part of project development. This can enable your teams to work more effectively together and reduce the negative effect of teams working in silos. 

All too often, when projects are commenced, involvement from key stakeholders is siloed, as compared to operating as a cohesive team. We want to help your company avoid the following security & privacy pitfalls where:

  • Project / application teams work in a vacuum, unaware of security or privacy concerns;
  • Privacy and security conduct their own assessments without any information sharing or collaboration; and
  • Security involvement is viewed as a final hurdle to overcome, just prior to “go live” for the project.



 The SPBD Excel checklists provide a wealth of experience to bake in security and privacy principles by establishing methodical and repeatable processes. 

  • NIST 800-160 is the "gold standard" on how to build security into the System Development Life Cycle (SDLC)
  • Logically-organized phases 
  • Task focus (How tasks support the lifecycle phases)
  • Task #
  • Activity Description
  • Reasonable Task Deliverables
  • Level of Effort (expectation for basics or enhanced requirements)
  • Stakeholder RACI Matrix (Responsible, Accountable, Consulted, Informed)
  • Mapping to leading practices:
    • NIST 800-160
    • NIST 800-53
    • ISO 27002


In addition to logically organizing steps, we went the extra mile by calling out the commonly-expected deliverables and tied them to a specific task # so both security and privacy teams are aware of expectations:  

  • Proposed solution is documented that captures security-relevant criteria and tentative requirements.
  • Listing of applicable statutory, regulatory and contractual requirements are defined.
  • Business & technical constraints are identified and documented.
  • Data classification is identified.
  • System criticality is identified.
  • Data protection requirements are defined (e.g., controls) based on data classification and system criticality.
  • "Best practices" are defined to be used in the design & implementation of systems, applications and services (e.g., OWASP, NIST, DISA, etc.).
  • System hardening baselines (e.g., configuration management requirements) are defined and documented.
  • Security Concept of Operations (CONOPS) is defined and documented.
  • Standardized Operating Procedures (SOP) are documented.
  • Service Level Agreement(s) (SLAs) are defined and documented.
  • Tentative life cycle is identified.
  • Roles and responsibilities for security requirements are assigned and documented.
  • Risk Assessment is conducted and a Risk Register (RR) is used to document findings.
  • Business Impact Analysis (BIA) is conducted and documented.
  • Privacy Impact Assessment (PIA) is conducted or modified.
  • Project stakeholder list is defined and documented (strategic personnel, business units and third parties).
  • Threat assessment is conducted and documented.
  • List of constraints (facts & assumptions) is defined.
  • Listing of expected systems and services that will be required to support the proposed solution is defined.
  • System Security Plan (SSP) is documented or modified.
  • Change Control Board (CCB) change request(s)
  • High Level Diagram (HLD) is documented.
  • Low Level Diagram (LLD) is documented.
  • Data Flow Diagram (DFD) is documented.
  • Plan of Action & Milestones (POA&M) is documented or modified.
  • End user training material is developed.
  • Security awareness training is provided.
  • Information Assurance (IA) testing (certification &accreditation) is commenced.
  • Key Performance Indicators (KPIs) are identified.
  • Authorization is granted (e.g., Authority To Operate (ATO) , Interim Authority To Operate (IATO) or Denied Authority To Operate (DATO)).
  • User Acceptance Testing (UAT) is conducted and documented.


Understanding Privacy & Security Starts With Defining Requirements

Understanding the requirements for both Security by Design (SbD) and Privacy by Design (PbD) principles involves a simple process of distilling expectations. This process is all part of documenting reasonable expectations to right-size the approach, since every organization is unique:

Editable Word Documentation


Click For An Example

Editable Excel Checklists


Click For An Example

  • The main SPBD document is an editable Microsoft Word document.
  • It is written at a program-level to provide direction and authority.
  • Defines how both Security by Design (SbD) and Privacy by Design (PbD) are going to be operationalized.
  • The SPBD comes with editable “paint by numbers” checklists for managing both privacy and security lifecycles.
  • Security checklists are based on NIST 800-160.
  • Privacy checklist is based on the OASIS Privacy Management Reference Model and Methodology (PMRM).

Professionally-Written, Editable NIST 800-160 & OASIS PMRM-Based Cybersecurity For Privacy by Design (C4P) Program

The Security & Privacy By Design (SPBD) product is designed to support your company’s existing policies and standards. Our solution is focused at the procedural and guideline levels.


Reducing Risk Through Cybersecurity For Privacy by Design (C4P)

The Security & Privacy By Design (SPBD) document supports your company’s existing policies and standards. Our solution is focused at the procedural and guideline levels. The SPBD document is focused on understanding risk associated with cybersecurity and privacy so that risk can be:

  • Reduced;
  • Avoided;
  • Transferred; or 
  • Accepted.

Implementing both Security by Design and Privacy by Design principles is a systematic way to find and address weaknesses, flaws and risks to your company.

  • Repeatable, methodical processes that seek out both security and privacy risk reduces the chance of surprises. 
  • Addressing security issues in an orderly manner gives your company a better assurance that gaps have been closed properly and as quickly as possible.


Zone-Based Approach To Secure Engineering

From a secure engineering and architecture perspective, it is worthwhile to take a zone-based approach to scoping an environment for secure systems engineering. This effort is meant to focus on particular systems of interest, while taking into account the systems elements and enabling systems that compose the system of interest. This supports the concept of Data-Centric Security (DCS), since the focus encompasses everything that either stores, processes or transmits the data in question, as well as the supporting infrastructure and services.

From this perspective, assets can be logically grouped into three (3) overlapping zones:

Zone 1 – The asset is a system of interest;

Zone 2 – The asset exists within the immediate operating environment of a system of interest; or

Zone 3 – The asset exists outside of the operating environment but influences the system of interest.


Methodical Approach To Privacy By Design (PbD) 

The OASIS Privacy Management Reference Model and Methodology (PMRM) is a privacy framework that assists in operationalizing Privacy by Design. Thee PMRM identifies eight (8) privacy services that are needed to operate at a functional level. These services are meant to clarify the “architectural” relationships and can be logically grouped into three (3) categories: Core policy services, Privacy assurance services; and Presentation & lifecycle services.


The Security & Privacy By Design (SPBD) includes an editable checklist for PMRM controls. This is tied to the security controls, so it is easy to link both cybersecurity and privacy requirements. This allows for a more cohesive assessment and encourages information sharing. The end product is a more comprehensive assessment of risk to both privacy and security. 






Sort by:

Sign up for our Newsletter!