When it comes to complying with the General Data Protection Regulation (GDPR), a common struggle organizations face is how to establish “what right looks like” in the absence of a checklist or prescriptive instructions.
Tom Cornelius, founder of the non-profit Secure Controls Framework (SCF) initiative, briefly touched on this exact challenge in my recent blog, GDPR Q&A with a Cybersecurity, Compliance and Privacy Expert.
We discussed the idea of leveraging existing security and privacy frameworks to address GDPR requirements. I promised to go deeper on using existing frameworks to accelerate or organize your GDPR compliance efforts, so let’s get started!
[Related: What Is GDPR Compliance?]
What is an IT Cybersecurity Framework?
An information cybersecurity framework is basically a set of blueprints to use for planning and establishing a program for security, risk management and reduction of vulnerabilities. Frameworks are usually created by experts and based on best practices
(a.k.a. established and proven methods for those of you who roll your eyes when you hear “best practices”).
Most organizations customize IT security frameworks for their unique use cases or security problems, often combining multiple frameworks to achieve their goals. The benefits of using frameworks are that you can save time in defining your requirements,
establish a set of priorities, and have a way to track your progress as well as your organization’s posture compared to peers using similar frameworks.
Using security frameworks can save you time in defining your requirements and establishing a set of priorities
What is ISO 27001?
The International Organization for Standardizations’ ISO 27001 is the gold standard for developing an IT cybersecurity strategy. It defines a broad spectrum of high-level to detailed
requirements for information security programs and can (should!) be used to measure the completeness of a company’s security program.
Mapping ISO 27001 to GDPR Security Controls
Using the Secure Controls Framework mapping we mentioned in our last blog, I selected the ISO 27001 (v2013) and GDPR check boxes for a comprehensive mapping of ISO 27001 security
controls to GDPR security controls. My results below only show direct mappings (so you don’t need scroll forever). I recommend implementation all the appropriate ISO 27001 compliance controls for your organization to establish a good foundation to develop your
cybersecurity program.
|
BONUS CONTROLS Example of how implementing these ISO 27001 controls will address other compliance controls |
|||||
| SCF # | SECURE CONTROLS FRAMEWORK (SCF) – CONTROL DESCRIPTION | ISO 27001 (v2013) |
GDPR | PCI DSS v3.2 | HIPAA |
| GOV-01 | Mechanisms exist to facilitate the implementation of cybersecurity and privacy governance controls. | 5.1 | Art 32 | 12.1 12.1.1 |
164.308(a)(1)(i) 164.316(a)-(b) |
| GOV-02 | Mechanisms exist to establish, maintain and disseminate cybersecurity and privacy policies, standards and procedures. | 5.2 | Art 32 | 12.1 12.1.1 |
164.308(a)(1)(i) 164.316 |
| PRM-01 | Mechanisms exist to facilitate the implementation of security and privacy-related resource planning controls. | 6.1
6.2 |
Art 32 | ||
| OPS-01 | Mechanisms exist to facilitate the implementation of operational security controls. | 8.1 | Art 32 | ||
| RSK-04 | Mechanisms exist to conduct an annual assessment of risk that includes the likelihood and magnitude of harm, from unauthorized access, use, disclosure, disruption, modification or destruction of the organization’s systems and data. | 8.2 | Art 35 | 12.2 | 164.308(a)(1)(ii)(A) 164.308(a)(1)(ii)(B) 164.308(a)(1)(ii)(D) 164.308(a)(7)(ii)(D) 164.308(a)(7)(ii)(E) 164.316(a) |
| RSK-04.1 | Mechanisms exist to maintain a risk register that facilitates monitoring and reporting of risks. | 8.3 | Art 35 | ||
| RSK-08 | Mechanisms exist to conduct a Business Impact Analysis (BIAs). | 8.2 | Art 35 Art 36 |
164.308(a)(1)(i) 164.308(a)(1)(ii)(A) 164.308(a)(1)(ii)(B) 164.308(a)(6) 164.308(a)(7)(ii)(E) 164.308(a)(8) 164.316(a) |
|
| RSK-09.1 | Mechanisms exist to assess supply chain risks associated with systems, system components and services. | 8.2 | Art 35 Art 36 |
||
| RSK-10 | Mechanisms exist to conduct a Privacy Impact Assessment (PIA) on systems, applications and services to evaluate privacy implications. | 8.2 | Art 35 Art 36 |
||
| CPL-02 | Mechanisms exist to provide a security controls oversight function. | 9.3 | Art 5 | 12.11 12.11.1 |
164.306(e) 164.308(a)(7)(ii)(D) 164.308(a)(8) 164.316(b)(2)(iii) |
| CPL-03 | Mechanisms exist to ensure managers regularly review the processes and documented procedures within their area of responsibility to adhere to appropriate security policies, standards and other applicable requirements. | 9.2 | Art 5 | ||
| VPM-04.2 | Mechanisms exist to identify and correct flaws related to the collection, usage, processing or dissemination of Personal Information (PI). | 10.1 | Art 5 | ||
| GOV-04 | Mechanisms exist to assign a qualified individual with the mission and resources to centrally-manage coordinate, develop, implement and maintain an enterprise-wide cybersecurity and privacy program. | 5.3 | 12.5-12.5.5 | 164.308(a)(2) 164.308(a)(3) 164.308(a)(4) 164.308(b)(1) 164.314 |
|
| GOV-05 | Mechanisms exist to develop, report and monitor cybersecurity and privacy program measures of performance. | 9.1 | 164.308(a)(6)(ii) 164.308(a)(8) |
||
| IAO-04 | Mechanisms exist to require system developers and integrators to create and execute a Security Test and Evaluation (ST&E) plan to identify and remediate flaws during development. | 10.1 | 6.6 | ||
| PRM-03 | Mechanisms exist to identify and allocate resources for management, operational, technical and privacy requirements within business process planning for projects / initiatives. | 7.1 | 164.308(a)(7)(ii)(B) 164.308(a)(7)(ii)(C) 164.308(a)(7)(ii)(D) 164.308(a)(7)(ii)(E) 164.310(a)(2)(i) 164.316 |
||
| PRM-07 | Mechanisms exist to ensure changes to systems within the System Development lifecycle (SDLC) are controlled through formal change control procedures. | 7.1 7.2 7.3 7.4 7.5 |
164.308(a)(1)(i) | ||
| RSK-05 | Mechanisms exist to identify and assign a risk ranking to newly discovered security vulnerabilities that is based on industry-recognized practices. | 8.3 | 6.1 | ||
| RSK-06 | Mechanisms exist to remediate risks to an acceptable level. | 8.3 10.1 |
164.308(a)(1)(ii)(B) 164.314(a)(2)(i)(C) 164.314(b)(2)(iv) |
||
| RSK-07 | Mechanisms exist to routinely update risk assessments and react accordingly upon identifying new security vulnerabilities, including using outside sources for security vulnerability information. | 8.2 | 6.1 | ||
| TDA-15 | Mechanisms exist to require system developers and integrators to create a Security Test and Evaluation (ST&E) plan and implement the plan under the witness of an independent party. | 10.1 | 6.6 | ||
| VPM-04 | Mechanisms exist to address new threats and vulnerabilities on an ongoing basis and ensure assets are protected against known attacks. | 10.2 | 6.6 | 164.308(a)(1)(ii)(A) 164.308(a)(1)(ii)(B) 164.308(a)(6)(ii) |
|
These mappings are focused specifically on security controls. There are additional ISO27k controls that can be mapped for more comprehensive coverage of GDPR privacy, risk assessment (DPIA), and breach detection and response. I recommend consulting other
sources in addition to the Security Controls Framework for guidance, such as:
- IAPP.org – Bridging ISO 27001 to GDPR
- ISO27k Forum – Mapping between GDPR and ISO27k
What is NIST 800-171?
NIST 800-171 refers to National Institute of Standards and Technology Special Publication NIST 800-171, which governs Controlled Unclassified Information (CUI) in
Non-Federal Information Systems and Organizations.
NIST 800-171 is basically a set of standards and processes for protecting information that is sensitive, but not “classified.” Organizations that process, store, or transmit CUI data for most federal and state agencies must comply with NIST 800-171.
Even if your organization is not required to comply with NIST 800-171, it provides a solid blueprint for establishing an IT cybersecurity program with the framework for addressing: access control, audit and accountability, configuration management, identification
and authentication, incident response, risk assessment, security assessment, and system integrity as well as other foundational organizational and technical controls.
[Related Reading: How to Perform a Cybersecurity Assessment]
Mapping NIST 800-171 to GDPR Security Controls
Now let’s take a look at NIST 800-171 (rev 1). According to the Secure Controls Framework, there are 13 NIST controls that I can use to address GDPR Articles 5, 24, 25, 32, 33, 34,
35, and 40.
|
BONUS CONTROLS Example of how implementing these NIST 800-171 controls will address other compliance controls |
|||||
| SCF # | SECURE CONTROLS FRAMEWORK (SCF) – CONTROL DESCRIPTION | NIST 800-171 (rev 1) | GDPR | PCI DSS 3.2 | HIPAA |
| CRY-01 | Mechanisms exist to facilitate the implementation of cryptographic protections controls using known public standards and trusted cryptographic technologies. | 3.13.11 | Art 5 Art 32 |
2.2.3 4.1 |
164.312(e)(2)(ii) 164.314(b)(1)-(2) |
| CRY-04 | Cryptographic mechanisms are utilized to protect the integrity of data being transmitted. | 3.8.6 3.13.8 3.13.16 |
Art 5 | 3.4 3.4.1 4.1 9.8.2 |
164.312(e)(2)(i) 164.312(e)(1) 164.312(e)(2)(i) |
| IRO-10 | Mechanisms exist to report incidents: ▪ Internally to organizational incident response personnel within organization-defined time-periods; and ▪ Externally to regulatory authorities and affected parties, as necessary. |
3.6.1 3.6.2 |
Art 33 Art 34 |
12.5.2 12.8.3 |
164.308(a)(5)(ii)(B) 164.308(a)(5)(ii)(C) 164.308(a)(6) 164.308(a)(6)(ii) 164.314(a)(2)(i)(C) 164.314(a)(2)(iii) |
| RSK-04 | Mechanisms exist to conduct an annual assessment of risk that includes the likelihood and magnitude of harm, from unauthorized access, use, disclosure, disruption, modification or destruction of the organization’s systems and data. | 3.11.1 | Art 35 | 12.2 | 164.308(a)(1)(ii)(A) 164.308(a)(1)(ii)(B) 164.308(a)(1)(ii)(D) 164.308(a)(7)(ii)(D) 164.308(a)(7)(ii)(E) 164.316(a) |
| CPL-02 | Mechanisms exist to provide a security controls oversight function. | 3.12.1 3.12.2 3.12.3 3.12.4 |
Art 5 | 12.11 12.11.1 |
164.306(e) 164.308(a)(7)(ii)(D) 164.308(a)(8) 164.316(b)(2)(iii) |
| SEA-01 | Mechanisms exist to facilitate the implementation of industry-recognized security and privacy practices in the specification, design, development, implementation and modification of systems and services. | 3.13.1 3.13.2 |
Art 5 Art 24 Art 25 Art 32 Art 40 |
2.2 | |
Where to start (for GDPR Compliance)
Organizations that need to comply with the GDPR should look to two different categories of existing frameworks to use as blueprints to get started:
- Cybersecurity frameworks such as ISO 27001/27002, NIST 800-53, NIST Cybersecurity Framework
- Privacy frameworks or privacy specific sections found in examples like ISO 29100, ISO 27018, HIPAA, and SOC2
Already an Alert Logic customer?
If you are an Alert Logic customer, we’ve got you covered with our managed cybersecurity offerings with security controls and 24×7 threat detection and monitoring
to address a broad set of security compliance requirements. The mapping below outlines the primary controls we address in addition to a broader set of controls and processes that
we can validate.
|
ISO 27001 / 27002 |
NIST 800-171 |
PCI DSS 3.2 |
GDPR |
SOC 2 (TSP 100) |
SOX 404 (COBIT 5) |
HIPAA & HITECH |
| 8.1 – Responsibility for assets. Inventory of assets. Ownership of assets. Acceptable use of assets. Return of assets.
12.2 – Protection from malware. Malware controls are required, including user awareness. 12.4 – Logging and monitoring. System user and administrator/operator activities, exceptions, faults and information security events should be logged and protected. Clocks should be synchronized. 12.6 – Technical vulnerability management. Technical vulnerabilities should be patched, and there should be rules in place governing software installation by users. 14.1 – Security requirements of information systems. Security control requirements should be analyzed and specified, including web applications and transactions. 16.1 – Management of information security incidents and improvements. There should be responsibilities and procedures to manage (report, assess, respond to and learn from) information security events, incidents and weaknesses consistently and |
3.1 Access Control (3.1.7, 3.1.8, 3.1.11, & 3.1.12)
3.3 Audit and Accountability (3.3.1, 3.3.2, 3.3.3, 3.3.4, 3.3.5, 3.3.6 & 3.3.8) 3.4 Configuration Management (3.4.3, 3.4.7, 3.4.8, 3.5.2, 3.5.3) 3.6 Incident Response (3.6.1, 3.6.2, 3.6.3) 3.11 Risk Assessment (3.11.2 & 3.11.3) 3.12 Security Assessment (3.12.3) 3.13 System and Communications Protection (3.13.1, 3.13.6 & 3.13.7) 3.14 System and Information Integrity (3.14.1, 3.14.2, 3.14.3, 3.14.4, 3.14.5, 3.14.6, 3.14.7) |
PCI 6.1 – Identify newly discovered security vulnerabilities
PCI 6.5 – Have processes in place to protect applications from common vulnerabilities such as injection flaws, buffer overflows and others PCI 6.6 – Address new threats and vulnerabilities on an on-going basis and ensure these applications are protected against known attacks. PCI 10.2 – Automated audit trails PCI 10.3 – Capture audit trails PCI 10.5 – Secure logs PCI 10.6 – Review logs at least daily PCI 10.7 – Maintain logs online for three months PCI 10.7 – Retain audit trail for at least one year PCI 11.2 – Perform network vulnerability scans by an ASV at least quarterly or after any significant network change (Includes 11.2.1, 11.2.2 and 11.2.3) PCI 11.4 – Use intrusion-detection and/or intrusion-prevention techniques to detect and/or prevent intrusions into the networks |
Article 24 – Responsibility of the controller: ensure and demonstrate processing is in compliance with GDPR
Article 25 – Data protection by design and by default Article 32 – Security of processing Article 33 – Notification of a personal data breach to the supervisory authority Article 34 – Communication of a personal data breach to the data subject Article 35 – Data protection impact assessment (DPIA) |
CC 3.2 – Risk Identification
CC 6.1 – Logical Access CC 6.2 – User Registration CC 6.3 – Access Modification and Removal CC 6.6 – External Threats CC 6.8 – Unauthorized and Malicious Code Protection CC 7.1 – Configuration and Vulnerability Management CC 7.2 – Security Event and Anomaly Detection CC 7.3 – Incident Detection and Response CC 7.4 – Incident Containment and Remediation CC 8.1 – Change Management |
DSS05.01 – Protect against malware
DSS05.02 – Manage network and connectivity security BAI03.03 – Develop solution components DSS05.02 – Manage network and connectivity security DSS05.04 – Manage user identity and logical access DSS05.07 – Monitor the infrastructure for security-related events DSS02.01 – Define incident and service request classification schemes DSS05.01 – Protect against malware DSS05.02 – Manage network and connectivity security DSS05.07 – Monitor the infrastructure for security-related events |
164.308(a)(1) – Security Management Process
164.308 (a)(5)(ii)(B) – Protection from Malicious Software 164.308(a)(6)(i) – Security Incident Procedures 164.308 (a)(1)(ii)(D) – Information System Activity Review 164.308 (a)(4)(i) – Information Access Management 164.308 (a)(6)(i) – Login Monitoring164.308 (a)(6)(iii) Response & Reporting 164.312 (a) – Access Control 164.312 (b) – Audit Controls 164.308 (a)(1)(ii)(A) – Risk Analysis 164.308 (a)(1)(ii)(B) – Risk Management 164.308 (a)(5)(ii)(B) – Protection from Malicious Software 164.308 (a)(6)(iii) – Response & Reporting |
To learn more about how Alert Logic can help you comply with the GDPR or other compliance requirements like PCI DSS Compliance, HIPAA, SOX or SOC 2, contact one of
our cyber security experts who can help you put together a plan that we can help you get up in running in days for a single monthly price (instead of
buying and integrating a bunch of compliance software tools and hiring more people).
Stay tuned for my next blog where I’ll break down GDPR Articles 33 and 34, what they mean, and what organizations need to do to comply.
