Cyber Security Law, Compliance, and Evidence

2021 information-assurance study note

This is a cleaned-up migration of a 2021 information-assurance post where I compared several legal and compliance frameworks that appear around cyber security work. I was not trying to write legal guidance; I was trying to understand what kinds of data, controls, records, and responsibilities each framework creates for security teams.

The frameworks I looked at were HIPAA, PCI-DSS, GDPR, GLBA, and SOX. I compared them by scope, affected organisations, control expectations, enforcement context, and the security work they create around access control, audit trails, logging, retention, breach response, privacy controls, vendor oversight, policy, and evidence.

What I compared

I treated each framework as a way to ask practical security questions:

• What type of data or business process is being protected?
• Which organisations or service providers are in scope?
• What controls, safeguards, or records are expected?
• What evidence would a security team need during an audit or incident?
• How does the framework affect monitoring, response, reporting, and accountability?

The examples cover different areas. HIPAA deals with health information. PCI-DSS deals with payment-card data. GDPR deals with personal data connected to people in Europe. GLBA deals with financial privacy and safeguards. SOX deals with financial reporting controls and corporate accountability.

PCI-DSS is an industry standard rather than a public law in the same way as HIPAA or GDPR, and SOX is not a cyber security law in the narrow sense. I included them because both still create security work: protecting payment systems, preserving trustworthy records, proving internal controls, and showing that sensitive processes are governed properly.

This page is a cyber security learning note, not legal advice.

HIPAA

The Health Insurance Portability and Accountability Act was signed into law in the United States in 1996. I looked at it as a healthcare privacy and security example: it covers protected health information and the way healthcare organisations handle it.

HIPAA applies to healthcare providers, health plans, healthcare clearinghouses, and business associates that process health information on their behalf. That includes groups such as hospitals, clinics, dentists, insurance providers, billing services, and other organisations that handle healthcare data.

I broke HIPAA down into several major rules:

• The Privacy Rule introduced national standards for protecting medical records and personal health information. It also gave patients rights around accessing, copying, and correcting their health records.
• The Security Rule focused on electronic protected health information and required administrative, physical, and technical safeguards.
• The Breach Notification Rule introduced notification duties after certain breaches of protected health information.
• The Omnibus Final Rule strengthened privacy and security protections and addressed gaps between HIPAA and related health information technology requirements.

The safeguards are not just technical settings. Administrative safeguards include policies, procedures, responsibilities, training, and risk management. Physical safeguards deal with access to facilities, equipment, and storage areas. Technical safeguards deal with systems, access, communication, auditability, and protection of electronic information.

In security work, HIPAA pushes attention towards access control, encryption decisions, audit logs, breach-response timelines, user training, vendor oversight, and evidence that safeguards are operating. Health data is sensitive, long-lived, and hard to repair once exposed, so the control environment around it has to be treated carefully.

I also looked at penalties and implementation difficulty. HIPAA violations are treated in categories, including situations where an entity could not reasonably have known, cases where it should have known, and cases involving wilful neglect. The 2021 version of this note included specific fine ranges, but those figures should be checked against current official sources before being relied on. I treated the implementation cost as part of the risk picture: healthcare compliance can be expensive and coordination-heavy, but the risk is tied to data that can cause real harm when mishandled.

PCI-DSS

The Payment Card Industry Data Security Standard was first introduced in 2004 by major payment-card brands, including American Express, Discover, JCB, Mastercard, and Visa. I looked at it as a shared industry standard for reducing payment fraud and defining technical and operational expectations around cardholder data.

PCI-DSS applies to organisations that store, process, or transmit credit or debit card information. That can include online businesses, physical retailers, service providers, and other organisations in the payment-processing chain.

The control areas map cleanly onto practical security work:

• build and maintain a secure network, including firewalls and secure configuration;
• avoid vendor-supplied defaults for passwords and security parameters;
• protect stored cardholder data;
• encrypt cardholder data when it crosses open or public networks;
• maintain secure systems and applications;
• restrict access to cardholder data by business need-to-know;
• assign unique IDs to users with computer access;
• restrict physical access to cardholder data;
• monitor and test networks;
• maintain an information security policy for employees and contractors.

I mapped PCI-DSS directly to segmentation, secure configuration, encryption, access control, vulnerability management, logging, monitoring, testing, and policy evidence. It takes familiar security ideas and turns them into a control framework that an organisation has to evidence.

Enforcement normally happens through the payment ecosystem, such as acquiring banks and payment brands, rather than a single public regulator. Fines, certification pressure, and processing consequences can vary by organisation size, duration of non-compliance, and the scope of the issue.

The trade-off I noted was practical. A shared standard helps create consistency across payment-card security, and regular updates allow the standard to respond to new risks. Implementation can still be awkward where systems overlap, business models change, or third-party payment services complicate the boundary of the cardholder-data environment.

GDPR

The General Data Protection Regulation came into effect on 25 May 2018. I studied it in the context of European privacy rights and earlier data-protection work, including the European Convention on Human Rights and the 1995 European Data Protection Directive.

GDPR is concerned with personal data relating to people in the European Union and European Economic Area. It can affect organisations outside Europe where they target, collect, or process data relating to people in scope of the regulation. That wider reach is why it appears so often in cyber security and privacy discussions.

The controls and requirements I focused on were transparency, consent, and individual rights. Organisations need to explain what data is collected, why it is collected, how it is used, and where tracking technologies such as cookies are involved. They also need to handle valid consent, provide opt-in and opt-out mechanisms where required, and understand the difference between controllers and processors.

The individual rights I covered were:

• the right to be informed;
• the right of access;
• the right to rectification;
• the right to erasure;
• the right to restrict processing;
• the right to object;
• rights around automated decision-making and human review.

For practical security work, GDPR connects privacy to data discovery, access control, retention, deletion, audit trails, breach reporting, third-party processing, and monitoring. Logs are a good example: they are valuable for security investigation, but they can also contain personal data and need to be handled properly.

The 2021 note discussed the well-known maximum fine structure of up to 20 million euros or 4 percent of annual global turnover. That should be read as historical study context rather than a complete enforcement guide. Personal data protection is not background paperwork; it changes system design, incident response, and business risk.

GLBA

The Gramm-Leach-Bliley Act was enacted in the United States in 1999. I looked at it as a financial privacy law concerned with how financial organisations explain information-sharing practices and safeguard sensitive customer data.

GLBA applies to companies that provide financial products or services, such as loans, financial advice, investment advice, and insurance. The data concern is customer financial information, including how it is collected, shared, disclosed, and protected.

I separated GLBA into three main rules:

• The Financial Privacy Rule requires organisations to explain how customer financial information is collected, used, and shared.
• The Safeguards Rule requires security controls to protect customer personal information, including audit procedures and information-disclosure controls.
• The Pretexting Rule addresses attempts to collect information under false pretences, including social-engineering-style activity.

In practical terms, GLBA connects to access control, monitoring, vendor oversight, staff procedures, audit evidence, and safeguards against misuse. The pretexting rule is especially relevant because it ties financial privacy to human attack paths as well as technical compromise.

I also looked at enforcement by the Federal Trade Commission and federal banking agencies, along with penalties for institutions and individuals. The exact figures should be treated as historical context. The security work created by GLBA is concrete: policies, access records, audit results, disclosure controls, and response processes all have to support the protection of customer financial information.

SOX

The Sarbanes-Oxley Act was passed in 2002 after major corporate accounting scandals involving companies such as Enron, WorldCom, and Tyco. I studied it as an accountability and recordkeeping law with a security impact, rather than as a cyber security law by itself.

SOX is concerned with financial reporting controls, recordkeeping, auditability, and corporate responsibility. Its security relevance comes from the systems and controls that support financial reporting.

The sections I focused on were:

• Section 302, which requires senior corporate officers to certify financial statements and disclosure requirements.
• Section 404, which requires internal controls and reporting methods that can prevent or discover problems.
• Section 802, which deals with recordkeeping, auditing, falsification, destruction of records, and retention expectations.

For security teams, SOX can affect identity and access management, change control, logging, monitoring, backup processes, audit trails, and evidence retention. If a system supports financial reporting, then privilege changes, data integrity issues, failed controls, or missing records can become audit and accountability problems.

SOX also helped me connect security controls to business trust. Stronger financial transparency and accountability can improve confidence in an organisation’s reporting, but the controls only mean something if they are owned, tested, documented, and backed by reliable evidence.

Evidence and security operations

After comparing the frameworks, I mapped them back to the security work they create.

HIPAA asks how health information is protected and how breaches are handled. PCI-DSS asks how cardholder data is protected. GDPR asks how personal data is processed, explained, and controlled. GLBA asks how financial customer information is shared and safeguarded. SOX asks whether financial records and controls can be trusted.

Technical findings often become evidence: access records, alert timelines, containment actions, escalation decisions, and explanations of impact.

This is where the topic links back to SOC and incident-response work. Logs and investigation notes are not just internal breadcrumbs. They may become part of the organisation’s explanation of what happened, who was affected, which controls operated, and what action was taken.

The cost side is also part of the picture. Implementing controls, auditing them, preserving evidence, and maintaining policy all take time and money. Weak security can cost far more when sensitive health, payment, personal, or financial data is exposed, but compliance work still has to be planned realistically.

Currentness note

This page is a historical learning note migrated from a 2021 WordPress post. It is not legal advice and should not be used as current compliance guidance.

Regulations, standards, official guidance, enforcement priorities, penalty ranges, and technical expectations change over time. Anyone applying HIPAA, PCI-DSS, GDPR, GLBA, SOX, or similar requirements should check current official sources and work with qualified legal or compliance professionals.