What compliance means in the context of cybersecurity and practicality

Just what are you complying with?

The whole point of compliance is to become capable of attesting to your organization’s capability to maintain security, as a documented fact.  You conduct an audit, you run your compliance checks, you implement verification plans, and perhaps you invest in independently staged penetration tests.  If the laws and regimens with which you comply neglect to define security itself, then with what are you complying in the end but an ideal?  Whose ideal is it?

Surprise:  It’s yours.  One of the unspoken aims of compliance is not just to demonstrate your organization’s commitment to security, but also its ability to raise the bar in redefining it.  Cybersecurity should be, when we aspire to it, the absolute, safeguarded protection of information so that its use is restricted to legitimate purposes, by applications that aim to use it honorably, up until the point that information becomes no longer necessary or irrelevant.  The word “absolute” implies a subjective concept.  It can and should be restricted to applying to something as inviolable in a thousand years as it is today: for example, your rights as a person.  In practice, “absolute security” may as well be an oxymoron.  Conceding such an ideal is feasible should be, in itself, a security vulnerability.

  It is the observance of, and dedication to, sound and demonstrably secure business practices, along with the methodologies presently attributed to those practices, that constitutes compliance.  When industries and organizations go above and beyond the law to follow accepted standards for safeguarding the security of sensitive and personal data, that is also compliance.  When an organization establishes its own practices with an eye towards exceeding the ideals put forth by a standard compliance regimen, that’s good governance.  But following that governance qualifies as compliance.

In the interest of the goals of organizational cybersecurity, the ideal of compliance is founded on the belief that following both established rules and regulations, as well as arbitrary or voluntary guidelines, will give organizations a solid foundation with which to establish a viable and effective security policy.  That also sounds like “governance,” but in practice, good governance is about the act of establishing and perfecting secure principles and practices.  Compliance, therefore, is about observing them and adhering to them, at least insofar as internal compliance is concerned.  With respect to existing laws and regulations, compliance demands a modicum of faith that the act of following and respecting them will lead to an enactment of better, more secure, and more sustainable information management methods, both throughout the enterprise and conceivably throughout the world.

Compliance and accordance

Unto itself, the term “compliance” triggers the aspirational goals that organizations instill upon their employees and stakeholders for maintaining both transparency and integrity, as well as their hopes to become perceived throughout the world as principled and honorable.  Once the term “cybersecurity” appears within four or five words of “compliance,” it’s like everyone in the organization experiences a costume change and assumes a different character with a weird ambiance.  Suddenly compliance is treated as being less about honor and principle, and more about thwarting attacks from clandestine foes and maintaining vigilance against almost alien bombardments.

One emerging school of thought that goes against this rather melodramatic tendency is to perceive cybersecurity compliance as a kind of power charger for an organizational security program.  The act of continually maintaining compliance — of being “plugged in” to frameworks and regulations — steadily elevates the organization between two evolutionary states over an often indefinite interval of time.  That continual vigilance is called accordance with the plan.  If you’re sticking with the compliance program, you’re said to be in accordance.

Of those two evolutionary states, the desired one is defined through the process of risk management.  While that desired state does incorporate the state of compliance, more broadly it represents the optimum state of the organization with respect to how much risk it can sufficiently tolerate as it pursues its stated business goals and objectives.  The work an organization does to become compliant moves it in the direction of this optimum state.  Thus the path towards achieving compliance eventually proceeds beyond compliance itself.

How and why a compliance framework improves resilience

The first thing a compliance framework provides an organization is a reasonable, achievable set of goals.  While adhering to and obeying the law is an honorable objective, goals in this context extend to practices that inspire trust and respect, both inside and outside the organization.  To enable that organization to attain a state of compliance, a framework must provide it with a structured itinerary whose broader aim isn’t just compliance with a law or even just a principle, but the pursuit of an ideal.

Implementing a compliance framework involves continually, periodically taking the following steps:

• Risk assessment — This is the process of identifying and cataloguing every known risk, then scoring their relative degrees of risk with respect to one another, both quantitatively and qualitatively
• Policy development — Through this process, the organization re-evaluates the efficacy of policies, including those already instituted through governance programs, and scores those policies as to their adherence to goals and performance objectives
• Training, awareness, and motivation — Ensuring that all employees and stakeholders are given access to materials, education, and continuous discussion about policies, ethics, standards, roles, and responsibilities
• Auditing and monitoring — Assessing the effectiveness of risk mitigation efforts, both with periodic checklists and continual platform-based observation
• Business continuity preparation — Evaluating the readiness and potential efficacy of the organization’s business continuity and disaster recovery plan (BC/DR) and taking steps prior to a disaster or catastrophic incident to maintain readiness
• Reporting and documentation — Meticulously recording evidence of how the organization is abiding by regulations and requirements, taking note of procedures being followed, the policies mandating those procedures, the controls used in implementing procedures, and the outcomes from that implementation

All of these components play roles in continuous improvement.  That is to say, you can’t really have continuous improvement as one of the many stages of accordance with compliance frameworks, because then it wouldn’t be continuous but occasional.  Risk assessment, reassessment, auditing, monitoring — all these tasks are undertaken in the interest of continuous improvement, so long as they’re done rigorously and according to a tight itinerary.

Laws and regulations that mandate cybersecurity measures

Especially if your organization does business with federal governments, certain compliance regimens may be mandated by law, and failure to adhere to them could incur fines and penalties.

Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA)

The CIRCIA law, passed by the US Congress in March 2022 and signed into law by President Biden, mandates that owners of assets that the United States classifies as critical infrastructure (e.g., refineries, communications facilities, dams, nuclear reactors, stock exchanges) must disclose information about breaches and other incidents with the Cybersecurity and Infrastructure Security Agency (CISA).

What’s important about this law from the perspective of overall security improvement is that compliance suggests the need for a standard format for reporting.  A CISA document published in April 2022 [PDF] lists ten key elements of an incident disclosure, then links to an Incident Disclosure Form that could become the prototype for a format that ensures transparency and interoperability.  Federal investigators may use information disclosed in this manner to establish patterns and pathologies that could help the world at large take defensive and offensive measures to stop cyber terrorism.  Conceivably, the common use of this format could extend beyond the domain of critical infrastructure, even into small business where cyber incidents have similar profiles.

FISMA

The original purpose of the US Federal Information Security Management Act of 2002 was to mandate that all government agencies, as well as all entities that conduct business with those agencies, plus all entities that receive federal grants, develop and implement agency-wide information security management programs to reduce or eliminate the number of cyber attacks.  This purpose was better articulated by the Federal Information Security Modernization Act of 2014, to which the acronym FISMA presently refers.  This amended law mandates that agencies and their partner and supplier organizations conduct periodic reviews on all aspects of their information systems, with the goal being to secure and protect the data, more importantly than the systems and networks that propagate it.

What FISMA brings to the table is a standardized set of metrics for assessing how well an organization manages its data, with respect to three principal security objectives as outlined by the National Institute of Standards and Technology (NIST):

• Confidentiality — Assigning the task of providing restrictions on access to personally identifiable information (PII) and proprietary data to authorized personnel, maintaining checks on those authorizations, and preserving the restrictions they apply to data
• Integrity — Ensuring the non-repudiation capability, authenticity, and completeness of information, and guarding against its unauthorized and improper modification and destruction
• Availability — Ensuring that authorized roles always have timely access to information which access controls, restrictions, and permissions enable them to obtain

These objectives are often referred to as the CIA Triad, which agents of the intelligence service probably stopped snickering at long ago.

US Health Insurance Portability and Accountability Act (HIPAA)

Signed into law in 1996, HIPAA applies strict mandates to how healthcare organizations in the US manage protected health information (PHI) pertaining to individuals.  The ideal to which HIPAA adheres is patient confidentiality.  To accomplish this, it mandates the use of protocols for the distribution, storage, and access of PHI, limiting its access only to people and entities with an established need to know.

Only in situations where lack of knowledge about a patient’s injuries or ailments threaten the lives and safety of others, may PHI be shared without express permission from patients to breach confidentiality.  For example, if a person sustained gunshot wounds, lack of knowledge about the nature of those wounds may endanger other individuals if the suspect remains at large.

HIPAA extends its mandates to cover financial institutions and insurance providers whose data accessibility extends to a person who may be, or may evidently become, a patient.  Mandates are also placed on educational institutions such as colleges and universities that keep medical information on file for their students.  The act enforces its mandates through the imposition of strict penalties for non-compliance.

Security Rule

This part of the HIPAA Act establishes safeguards for the use of electronic PHI, and requires and enacts their enforcement by any entity that would be authorized to utilize PHI.  The Security Rule has become a kind of template for the protection of PII, or any data that could be attributed to a person or persons, for industries outside of healthcare.

Privacy Rule

HIPAA’s Privacy Rule establishes further safeguards to how PHI may be disclosed to other people, both through electronic means as well as written and oral communication.  It limits the extent to which PHI may be disseminated between parties or entities without the authorization of the person to whom the information pertains.

US Gramm-Leach-Billey Act (GLBA)

Enforced by the US Federal Trade Commission, the GLBA Act establishes mandates for how financial institutions collect and use non-public personal information (NPI).  Think of NPI as the counterpart of PHI that pertains not to health but to wealth.  Any data that could link to a person’s financial information is covered by GLBA, including Social Security numbers.

Safeguards Rule

The safeguards mandated by GLBA must be instituted by any organization that conducts what the FTC defines as “financial activities” on behalf of clients or customers, including stockbrokers, tax preparers, real estate lenders, and credit unions.  A company that extends credit to a customer towards the purchase of goods or services, whether or not that company is technically a retailer, may be subject to GLBA.

Privacy Rule

Most importantly, a person whose NPI may be shared with another party must be provided with a notice of intent to share, and that person must be given the opportunity to opt out.  Although GLBA mandates that financial institutions must maintain a privacy policy, it does not stipulate what such a policy must contain.

US Sarbanes-Oxley Act (SOX)

The SOX Act is much more extensively involved with cybersecurity and electronic data protection of non-public information than GLBA.  SOX’s enactment was notable for the very strict controls it attaches to corporations’ public disclosures of their financial information, broadening and clarifying the legal definition of fraud.

Elements of SOX have been enacted into law in stages since 2002, soon after the financial crisis brought on by the revelation of fraudulent practices by Enron, which had become the world’s seventh largest company.  In 2023, the US Securities and Exchange Commission enacted the so-called “SOX Final Rule,” mandating that any financial institution or entity bound by law to abide by SOX’s mandate for transparency in financial disclosures, also be bound to periodically disclosing the following:

• How the entity assesses, identifies, and manages its cybersecurity risks
• The identity of roles within the entity that are responsible for managing the assessment process
• The extent to which the entity’s Board of Directors oversees the assessment process

It’s the first item that merits the most attention, because it codifies into law the existence of risk management processes for any entity that provides financial services.  When any financial services entity fails to report its cybersecurity incidents, the trading prices for that entities’ securities and other financial assets could become misstated.  That, in and of itself, is a security vulnerability, enabling malicious actors to make dubious trades prior to knowledge of these incidents becoming public.  For IT teams to comply with the SOX Final Rule, they must cooperate directly with financial audit teams.

Payment Card Industry Data Security Standard (PCI DSS)

As a means of combatting identity theft and credit card fraud, the world’s credit card issuers collectively made it mandatory for the retailers and other payment processors worldwide that rely upon them to adhere to the PCI DSS standards framework. These retailers are contractually obligated to comply, or otherwise face penalties capped at USD $500,000.

The major requirements of PCI DSS compliance are far from surprising, including these:

• Payment processors must ensure that all processes are documented and communicated to all payment system users.
• System components used in payment transactions are kept in documented inventory.
• A formal security policy must be implemented and maintained.
• Payment terminals must be routinely and regularly inspected, and the results of those inspections documented and available for review.
• Staff handling payment processing systems must be regularly trained and re-trained.
• Data pertaining to credit transactions must be securely disposed of when no longer necessary to maintain proper bookkeeping.

EU General Data Protection Regulation (GDPR)

With an eye toward how rapidly the problem of protecting personal data has scaled out, the European Union’s GDPR mandates that cybersecurity professionals take “appropriate technical and organizational measures” to process and manage PII.  As if to underscore the variable and dynamic nature of what constitutes proper security conduct, Article 32 of the GDPR invokes the word “appropriate” twice in the same sentence.

While the GDPR adopts arguably the most robust system of penalties for any country or region anywhere in the world, rather than explicitly specifying what constitutes proper management conduct or improper conduct, the Regulation relies on seven key principles (or just six, depending on who’s doing the counting):

• Lawful basis — For any organization to process anyone’s personal information, it must have established a lawful basis for its right to do so.  That basis must qualify as one or more of the following:
  • Express consent from the person whose information is being processed
  • A contract with the person specifying the exchange of personal information
  • Compliance by the processing entity with a legal obligation on that entity — for instance, the act of securing the information itself
  • An action by the processing entity that can be justified as being in the vital interests of the person to whom the information pertains
  • An action justifiable as being in the interests of the general public
  • An action justifiable as being in the legal and legitimate interests of the organization doing the processing (for instance, avoiding a civil lawsuit for mishandling of information), with the exception being when the person to whom the data pertains has expressly overridden the organization’s rights to do so
• Legitimacy — An organization may only collect personal information for a specific and documented purpose, not just to have it available in case a future application for it comes along.  (This is a major point of contention in recent legal challenges over generative AI proprietors alleged to be training their large language models using data from a multitude of unchecked sources, without first having a clear mission statement about what they intend to do with it.)
• Minimization — The amount of PII that an organization may collect must be limited to the smallest amount necessary to accomplish the stated objective or purpose.
• Accuracy — Personally identifiable information must be kept up-to-date and accurate, because the use of inaccurate or invalid data about a person may be injurious to that person.
• Retention — Data containing PII may only be retained by an organization for the duration of its usefulness to the application that requires it, and no longer.
• Confidentiality — The organization processing PII must ensure “appropriate security of the personal data, including protection against unauthorized or unlawful processing and against accidental loss, destruction, or damage, using appropriate technical and organizational measures.”  As long as the organization follows the most current editions of the GDPR Compliance Checklists, it can make the legal claim — should it ever come to this — that it aims to ensure appropriate security through appropriate means.
• Accountability — The person in the organization ultimately responsible for overseeing compliance activities must be capable, at any time, of demonstrating compliance with documented evidence.  (By this writer’s count, that makes seven.)

Assertions of personal rights

The assertion that each person has the right to override the organization’s right to retain data about them, is made in several places, including the following:

• Article 15 states each person has the right to access any data that has been collected about them; and Article 20 states that data must be presented in a common or machine-readable format
• Article 17 asserts the “right to erasure” or “right to be forgotten”, giving each individual not only the right but the means to instruct the collecting entity to remove all data pertaining to them
• Article 22 is curious and still the subject of ongoing controversy, particularly with respect to how it interprets the work of applications.  Ostensibly, it asserts the individual’s right not to have decisions about their life be made by automated processing.  Theoretically, it could apply to a person who may object to having their driving license suspended, along with countless others, on account of some automated rule where no human intervention was applied.  In practice, automated batch processing is part of the very nature of database management, so Article 22’s enforceability remains at issue.

California Consumer Privacy Act (CCPA)

The CCPA is the State of California’s conscious effort to implement a framework based on, or at least inspired by, GDPR.  It’s a statewide law protecting citizens’ rights regarding information collected about them by anyone, regardless of whether the collectors do business in California.  While the similarities between CCPA and GDPR are obvious, California implemented some intentional differences in its approach to ensuring privacy and data integrity:

• Right to object — CCPA opts not to take the GDPR route of stipulating that an organization must have a “legal basis” to collect someone’s data.  Instead, CCPA states that a business must notify an individual not only when it collects personal information but if it also intends to reserve the right to sell that information to someone else.  This would give that person the means to object, and put an immediate stop, to such a sale.  This is the only time when CCPA mandates that individuals’ “right to opt-out” be recognized.
• Accountability — The seventh principle of GDPR, which some observers believe to be absent or at least virtually non-existent, is clearly absent from CCPA.  Although CCPA does require organizations to train their staffs with respect to enabling their customers to exercise their rights regarding their PII, it does not explicitly state that documentation and evidence must be kept and maintained.
• Exclusions — The CCPA’s statutes explicitly apply solely to for-profit organizations that do business in the State of California, whose annual gross revenue is in excess of $25 million, and at least half of whose revenue is derived from a business practice where PII is sold to others.  CCPA also explicitly excludes healthcare information and PII related to financial information from its statutory authority, since both of these classes would presumably be covered by HIPAA and GLBA, respectively.

New York SHIELD Act

In 2019, the State of New York expanded and intensified its approach to protecting PII for persons living in the state.  The way New York perceives PII is pretty straightforward:  If access to a person’s data is restricted by means that are specific to that data alone, then that’s enough to signify it must be private data.  Under the 2005 law the SHIELD Act replaced, data was only considered private if it used a code (what database engineers would call a “private key”) to identify a person, in any record that included that person.  A Social Security number could serve as such a code.  Of course, asserting in court that the code was private usually meant divulging that code.  Now, data is private if a person may access it using a password access code, biometric data, e-mail address, username, or any combination.

SHIELD now mandates that organizations conducting business in New York must implement “reasonable technical safeguards” to protect PII, yet it does expand its definition of that concept to include the design of the software using the PII.  In other words, if your organization uses software that is generally known to be vulnerable, the case could be made that merely slapping endpoint protection on that software would not fully qualify as a “reasonable” safeguard.  Businesses that experience a data breach must coordinate with law enforcement to notify individuals who may be impacted, in a timely manner.

LEARN MORE FROM SIMPLERISK

• Streamline Your Information Security Program with SimpleRisk’s Ready-Made Templates by Josh Sokol, CEO, SimpleRisk
• PCI DSS Compliance
• HIPAA Compliance

Voluntary standard frameworks

Laws and regulations cannot reasonably codify the measures and methods each organization should take to meet their stated objectives of “reasonable” security.  If they tried, they would soon find themselves as rapidly outmoded as the previous model of any given smartphone.  What makes an organization’s compliance with laws and regulations undeniable is their attestation to following a compliance framework.

ISO 27001, ISO 31000, and NIST CSF 2.0 are not laws.  But if your organization follows their frameworks and meets their objectives, it makes a firm foundation for itself when asserting that it’s abiding by the spirit of the law.  These frameworks have greater flexibility to adjust to the evolving security requirements of enterprises and their data centers, without endangering the enforceability of laws that are usually only subject to change once they’ve aged enough to have become archaic.

ISO/IEC 27001

The 27001 framework is intentionally designed to meet the requirements of the FISMA Act, especially with respect to its recognition of the CIA Triad.  Although FISMA applies to US federal agencies and entities that do business with them, any organization seeking ISO 27001 certification with the intention of demonstrating to stakeholders and partners that it is dedicated to the protection of the data they share amongst each other, that’s necessary for them to conduct business.  (The International Electrotechnical Commission is co-publisher of the standard along with the International Organization for Standardization.)

Each activity an organization undertakes in following ISO 27001 is referred to as a control.  Think of the framework as though it were a mechanical machine, on the surface of which knobs, dials, and buttons are directly connected to mechanisms that influence the organization’s security profile.  These metaphorical knobs, dials, and buttons correspond with the controls in a security framework.

ISO 31000

The 31000 standard takes a similar approach to how ISO perceived compliance in terms of proactive methods, and applies it to the field of risk management.  How ISO 31000 perceives risk management is very much in keeping with how SimpleRisk perceives this process, especially with respect to identifying individual risks first and assessing their potential priorities and impacts exclusively.  It espouses the use of a common set of metrics for evaluating and scoring risk, and builds on ISO standards 27001 and 27002 by enabling organizations to directly integrate cybersecurity activity with risk management activity.

NIST Cybersecurity Framework (CSF) 2.0 

The key purpose of NIST CSF is to fill in all the gaps — not just the omissions in laws and regulations stating what security is and should be, but also the ideals and aspirations of organizations seeking to articulate their security goals in a manner aligned with what certain laws would call “reasonable.”  CSF introduces itself as a sort of all-purpose supplement, identifying the organization’s core functions and giving them a path to follow towards identifying, and finally asserting, what their security goals are:

To that end, CSF suggests a six-step methodology, comprised of so-called Core Functions, the final outcome of which is the identification of desirable cybersecurity outcomes:

• Govern — Introduces organizations to enterprise cybersecurity in a practical, more organized context, defining the roles, risks, and responsibilities of security managers and directors, and establishing what it means to determine policy
• Identify — Provides the categories of assets used in identifying risks and their impact on the organization
• Protect — Identifies the safeguards that are feasible for securing identified assets, enabling training, education, and awareness measures for implementing those safeguards
• Detect — Introduces organizations to the concept of continuous monitoring, adverse event analysis, and other means of ascertaining threat profiles
• Respond — Reveals to organizations how they can strategically contain and mitigate the impact of threat events and incidents, including through proper and transparent reporting and communication
• Recover — Provides a blueprint for how an organization can recover to normal operating status, or something approaching it, in the wake of a security incident

LEARN MORE FROM SIMPLERISK

• Using the ISO 27001 Control Framework with SimpleRisk by Josh Sokol, CEO, SimpleRisk
• Simplifying the NIST Cybersecurity Framework with SimpleRisk by Josh Sokol, CEO, SimpleRisk
• How to Integrate HITRUST CSF and the Secure Controls Framework in Your GRC Strategy by Alan Proctor, Chief Compliance Officer, SimpleRisk

Trust Services Criteria (SOC 2)

One respected method for an organization to demonstrate its commitment to the principles of compliance is to follow the Service Organization Controls 2 compliance regimen, and submit to independent SOC 2 audits.  The SOC 2 Framework, also called Trust Services Criteria, presents organizations with a questionnaire enabling them to self-assess their use and adherence to a substantial number of security controls, before presenting that information to accredited SOC 2 auditors.  The five categories covered by SOC 2 are: Security, Availability (more specifically, the availability of services to customers), Processing Integrity, Confidentiality, and Privacy.  An organization’s full compliance with SOC 2 implies it also acts in accordance with the laws and regulations of the countries, states, and provinces were it conducts business.

LEARN MORE FROM SIMPLERISK

• From Audit Fatigue to Efficiency: How SimpleRisk Empowers Auditors by Alan Proctor, Chief Compliance Officer, SimpleRisk
• 6 Ways to Create a Repeatable, Scalable Compliance Program by Michael Rasmussen, GRC 20/20