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:

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
effectively, and to collect forensic evidence.

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.

Fortra's Alert Logic
About the Author
Fortra's Alert Logic

Related Post

Ready to protect your company with Alert Logic MDR?