A common phrase in IT security is, “Compliance does not equal security.” The statement implies that because an organization can be hacked even if it is compliant with a cybersecurity framework or regulation, then compliance is essentially useless. Of course, if the test of compliance is to guarantee that an organization cannot be the victim of a cyberattack, then “security” does not equal security, either.
One useful description of cybersecurity compliance states: “Cyber compliance refers to the process of ensuring that an organization adheres to industry regulations, standards, and laws related to information security and data privacy.”1 Another explains that “IT compliance is the process of making sure your company’s technology systems and practices follow legal requirements, industry standards, and regulatory frameworks to keep your sensitive data secure.”2
If an enterprise believes that compliance, i.e., adhering to industry standards, legal requirements, and regulations, is a wasted effort unless the result is that the organization becomes an impregnable cyberfortress, then yes, compliance may seem to be a misplaced effort. This begs the question: What would organizations replace such standards, requirements, and regulations with? Organizations are unlikely to produce something better than what the US National Institute of Standards and Technology (NIST), International Organization for Standardization (ISO), Payment Card Industry Security Standards Council, etc., have already created.
It is essential that every organization understands its internal definition of compliance. To some, compliance might mean doing the least amount possible merely to claim that a certain set of controls has been implemented. In that case, taking a similar bare minimum approach to security is unlikely to yield better results than compliance. Or is compliance passing an audit? An audit is a point-in-time review of a sample from a set of controls. Is compliance a matter of working to comprehensively and effectively implement a set of controls? In the end, being compliant with regulatory requirements does not automatically translate to doing something merely to check a box. Whether regulatory requirements lead to benefits or wasted effort ultimately depends on the organization’s approach to them.
Setting Realistic Expectations
It is unrealistic to expect that any set of controls will make an organization impervious to a breach. In that sense, compliance does not equal security. A more productive view of compliance may be to look at it as a foundation.
Compliance, minimally, should address basic security hygiene requirements. As with a building, the foundation is something to support the rest of the structure. In the case of cybersecurity, a foundation of compliance is needed to support additional risk-based controls that an organization determines it needs to implement based on its industry, the information it processes and stores, and the threat landscape that it faces.
In the case of cybersecurity, a foundation of compliance is needed to support additional risk-based controls that an organization determines it needs to implement based on its industry, the information it processes and stores, and the threat landscape that it faces.Tailoring Controls for the Organization
It is worth noting that control frameworks and regulations do not put themselves forward as the total solution to an organization’s cybersecurity needs. For example, NIST published NIST SP 800-53B, Control Baselines for Information Systems and Organizations, to support an organization’s tailoring of SP 800-53 to its needs. The “Tailoring Control Baselines” section of NIST SP 800-53B outlines the tailoring process:
After selecting an appropriate control baseline, organizations initiate a tailoring process to align the controls more closely with the specific security and privacy requirements identified by the organization … Risk-related issues such as cost, schedule, and performance are considered in the determination of which controls to employ and how to implement controls in organizational systems and environments of operation.3
Among other tasks listed is “supplementing baselines with additional controls and control enhancements.”4 Even if a high or moderate baseline is selected, SP 800-53 includes many additional controls and control enhancements beyond those baselines that could be implemented by users for their organization. An example would be enhancement AC-2(7), Privileged User Accounts, which includes requirements that are not in any of the baselines but describe additional controls over privileged accounts. These additional controls could be used by organizations to address risk specific to the organization or its industry.
Similarly, the PCI Security Standards Council, in its publication Best Practices for Maintaining PCI DSS Compliance, notes that:
[The Payment Card Industry Data Security Standard] (PCI DSS) provides a minimum set of security requirements for protecting payment card account data. PCI DSS controls alone may not be sufficient to adequately mitigate all the risk associated with other types of sensitive data organizations may possess and should therefore not be used as a comprehensive checklist for addressing all security needs. It is likely that additional controls may be needed depending on the size, complexity, and business model of an organization.5
Compliance and Security Complement Each Other
A robust cybersecurity program may include compliance with regulatory requirements as an effect and as a benefit. From the PCI Security Standards Council, “Organizations that focus solely on compliance often do so to the detriment of security. A more effective approach is to focus on building a culture of security and protecting an organization’s information assets and IT infrastructure and allow compliance to be achieved as a consequence.”6
Similarly, a rigorous and thorough compliance program can provide the structure and processes needed to support cybersecurity. The design and execution of a compliance process, one that results in evidence that documents the execution of a control, shares some parallels with cybersecurity. If cybersecurity processes are not producing evidence and a comprehensive audit trail, there are likely gaps in the scope (all the entities subject to the control) or degree (all the aspects of the control) of its execution.
Ultimately, an organization can leverage compliance to improve its cybersecurity program and posture.
Challenges With Compliance
A significant challenge of—and often a complaint about—regulatory compliance is that organizations are frequently subject to multiple sets of regulations if they conduct business across different industry verticals or regions. Frameworks such as the Unified Compliance Framework (UCF) or the Secure Controls Framework (SCF) provide products that map controls from multiple regulations or control frameworks into a set of common requirements.7 This approach produces a master set of controls compiled from individual regulations and frameworks that should reduce the overall number of controls that organizations must implement and track. The UCF “maps global regulatory controls from authority documents covering information technology, physical security, records management, privacy, and third-party supply chain.”8 An authority document could be an internal organizational governance document or any that forms regulations, principles, standards, guidelines, best practices, policies, or procedures. Similarly, SCF can be used to build secure and compliant cybersecurity and data privacy programs.9 In addition to mappings such as UCF and SCF, organizations can also create their own mappings to document common and overlapping requirements from multiple regulations and other sets of controls.
Responding to Outdated Controls
Outdated compliance requirements can also cause issues for organizations. For example, regulations and control frameworks may still require password complexity to be enabled. However, NIST SP 800-63B-4 notes that requiring password complexity may result in user frustration and minimal reduction in the use of insecure passwords.10
When requirements become outdated or are out of sync with recommended practices, it may fall to the governance, risk, and compliance (GRC) team to present the rationale for implementing a control that, based on recommendations from a respected source such as NIST, does not match control specifications word-for-word. For example, when next-generation antimalware replaced signature-based antivirus software, it was possible to defend not conducting the scheduled scans that the legacy antivirus software required. To satisfy auditors, how a new solution works should always be explained, and the appropriate product documentation provided.
Flexibility for Risk-Mature Organizations
Rather than require organizations to secure data with specific controls, the PCI Security Standards Council took an interesting approach to PCI DSS v4.0.11 The new “customized approach” provides an alternative to implementing prescribed requirements—the “defined approach”—by allowing organizations to implement their own solution if it meets the intent of the requirement. The customized approach focuses on the Customized Approach Objective of a given PCI DSS requirement that emphasizes the outcome over implementation details. The aim is to offer more flexibility for organizations that want to use approved alternative security controls or technologies.12 While it may not have been the primary intention of introducing the customized approach, this way of stating the requirements also provides some protection against requirements becoming dated between releases, since the focus is on the outcome and not the details of how to achieve it.
While risk-mature organizations can implement a customized approach, less mature organizations should fall back on the defined approach to meet PCI DSS requirements. This is a benefit of regulations and control frameworks in general: They provide implementation details to entities with less-mature risk management and limited (or no) dedicated cybersecurity staff. It is possible that such organizations are not yet capable of performing a viable risk assessment to create their own risk-driven approach to cybersecurity, and they will need controls that include specifications about their implementation.
Opportunities for Comment
If organizations believe that the regulations and other requirements to which they are subject include controls that are ineffective or outdated, there is typically ample opportunity to provide feedback during the revision process to the entities that own the regulations and frameworks. As NIST includes in many of its publications, “Organizations are encouraged to review draft publications during the designated public comment periods and provide feedback to NIST.”13
In the United States, federal cybersecurity requirements are subject to the rulemaking process. This process requires that the agency creating the rule “generally must first provide notice that it intends to promulgate a rule … The notice must provide (1) the time, place, and nature of the rulemaking proceedings; (2) a reference to the legal authority under which the rule is proposed; and (3) either the terms or subject of the proposed rule. The agency must then allow ‘interested persons an opportunity’ to comment on the proposed rule.”14
These are several examples of government agencies responding to comments received. In the United States, the Security and Exchange Commission (SEC) in Final Rule: Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure noted that “We are making a number of important changes from the Proposing Release in response to comments received.” The SEC notes that changes included “narrowing the scope of disclosure, adding a limited delay for disclosures that would pose a substantial risk to national security or public safety.”15 In the European Union, similar comments were solicited when finalizing the Digital Operational Resilience Act (DORA).16 In the Final Report on Draft RTS on ICT Risk Management Framework and on Simplified ICT Risk Management Framework, the section “Feedback on the Public Consultation” summarizes the comments received and the responses to them. Notably, the comments changed the approach to proportionality to take into account elements of reduced complexity or risk and lessen the regulatory burden accordingly.17
Compliance does not guarantee that an organization is secure.Furthermore, the PCI Security Standards Council has a “Request for Comments” process that stakeholders can use to provide feedback on new or existing standards.18 There are various ways to comment on the content of and participate in the revision of regulations and industry standards if individuals or organizations wish to do so.
Conclusion
Compliance does not guarantee that an organization is secure. However, that does not mean it does not serve a purpose. Compliance ensures a minimum set of foundational requirements are met. Ideally, that covers the basics of cyberhygiene. No framework advises users to take the actions it recommends and then cease all efforts. Ultimately, it must be asked: Having built the foundation, what additional controls does it make sense for an organization to implement to further enhance security?
Attempting to implement security without the structure and process typically associated with compliance is likely to result in the partial implementation of a set of controls that apply to some of the entities that are in scope, some of the time. The rigor of compliance, such as the need to generate an audit trail to provide evidence that a control has been implemented as designed across the intended scope of the control, is essential to a robust cybersecurity program.
Endnotes
1 Miller, J.; “Cybercompliance 101: What It Is and Why it’s Needed,” Indiana Cybersecurity Hub, 1 February 2023
2 Howerton, T.; “IT Compliance: A Definition,” Cloud Security Alliance, 3 April 2025
3 National Institute of Standards and Technology (NIST), NIST Special Publication 800-53B, Control Baselines for Information Systems and Organizations, USA, October 2020
4 NIST, Special Publication 800-53B
5 Maintaining PCI DSS Compliance Special Interest Group, PCI Security Standards Council, Information Supplement: Best Practices for Maintaining PCI DSS Compliance, January 2019
6 Maintaining PCI DSS Compliance Special Interest Group, PCI Security Standards Council, Information Supplement
7 Unified Compliance, Unified Compliance Framework; Secure Controls Framework, “Cybersecurity and Data Privacy Metaframework”
8 Unified Compliance, Unified Compliance Framework
9 Secure Controls Framework, “Cybersecurity and Data”
10 NIST, NIST Special Publication 800-63B, Digital Identity Guidelines Authentication and Lifecycle Management, USA, June 2017
11 PCI Security Standards Council, PCI DSS, 2024
12 Goodspeed, L; “PCI DSS v4.0: Is the Customized Approach Right For Your Organization?,” PCI Security Standards Council, 29 August 2022
13 NIST, Special Publication 800-63B
14 Carey, M.P.; An Overview of Federal Regulations and the Rulemaking Process, Congress, USA, 19 March 2021
15 US Securities and Exchange Commission, “Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure”
16 European Commission, "The Digital Operational Resilience Act (DORA)," European Union
17 European Banking Authority, European Insurance and Occupational Pensions Authority, European Securities and Markets Authority, Final Report: Draft Regulatory Technical Standards to Further Harmonise ICT Risk Management Tools, Methods, Processes and Policies as Mandated Under Articles 15 and 16(3) of Regulation (EU) 2022/2554, Joint Committee of the European Supervisory Authorities, 17 January 2024
18 PCI Security Standards Council, “Request for Comments”
Tom Schneider | CISA, CCSP, CISSP, PCIP
Is an IT and cybersecurity professional with more than 35 years of experience. He began his career as an application programmer before becoming a system programmer for various IBM products. In that role, he led a team drafting a worldwide security standard for MQSeries, a messaging and queuing product. Schneider seeks to help organizations improve communication between governance and technical teams.
