⚖️ Laws, Compliance & Standards — Points 751–800
The legal and compliance layer of cybersecurity is tested in every interview, certification, and audit. Understanding not just what each law says but why it exists and how it affects security operations makes the difference between a candidate who knows acronyms and one who understands the profession.
Format: No. → Concept → Interview Answer → Example / Tool
Each row gives you the concept name, a one-sentence answer you can speak in an interview, and a concrete real-world example or standard reference.
Cyber Laws and Data Protection (751–780)
| # | Concept | Interview Answer | Example / Reference |
|---|---|---|---|
| 751 | Cyber law | Body of law governing digital activity, online crime, electronic evidence, privacy, and technology-enabled transactions. | Computer Fraud and Abuse Act (CFAA), Computer Misuse Act (UK) |
| 752 | IT law | Legal rules covering software, networks, digital contracts, data handling, and online services. | E-commerce law, software licensing agreements, SaaS contracts |
| 753 | Data protection law | Legal requirements for collecting, processing, storing, and deleting personal or sensitive data. | GDPR (EU), CCPA (California), PDPA (Singapore) |
| 754 | Privacy law | Rules defining how organizations may collect, use, share, and secure personal information with individual rights. | Right to access, right to erasure (GDPR Article 17) |
| 755 | Digital signature law | Legal recognition of cryptographic signatures as valid, enforceable evidence of intent and authenticity. | eIDAS (EU), ESIGN Act (US), DocuSign contracts |
| 756 | Electronic transaction law | Laws making electronic records, contracts, and payments legally valid under defined conditions. | UETA (US), online purchase agreements, digital invoices |
| 757 | Cybercrime law | Statutes criminalizing unauthorized access, malware deployment, fraud, identity theft, and related digital offenses. | CFAA prosecution for unauthorized computer access |
| 758 | Intellectual property law | Legal framework protecting software, designs, source code, and brand assets from unauthorized use or theft. | Copyright on source code, patent on encryption method |
| 759 | Copyright law | Rules protecting original creative works including code, documentation, and media — automatic upon creation. | Unauthorized copying of proprietary software = infringement |
| 760 | Trademark law | Rules protecting names, logos, and branding that identify a product or organization in commerce. | Fake site impersonating a brand = trademark infringement |
| 761 | Patent law | Rules protecting novel inventions and processes — requires registration and has a time limit. | Patented cryptographic hardware design (20-year protection) |
| 762 | Data breach notification law | Requirements for notifying regulators, customers, or partners when protected data is exposed. | GDPR: 72-hour regulator notification; 50 US state breach laws |
| 763 | GDPR | EU regulation defining lawful processing bases, individual privacy rights, breach obligations, and cross-border transfer rules. | Data subject access requests, right to erasure, DPO appointment |
| 764 | HIPAA | US healthcare regulation protecting Protected Health Information (PHI) with administrative, technical, and physical safeguards. | Access controls and audit logs for electronic patient records |
| 765 | PCI DSS | Payment Card Industry Data Security Standard — 12 requirements protecting cardholder data environments. | Network segmentation, tokenization, and quarterly vulnerability scans |
| 766 | ISO 27001 | International standard for establishing, implementing, maintaining, and continually improving an ISMS. | Formal risk assessment, ISMS scope, certification audit |
| 767 | ISO 27002 | Supplementary control guidance for ISO 27001 providing a catalog of 93 security controls with implementation guidance. | Reference for specific control selection and implementation |
| 768 | NIST CSF | Voluntary risk-based framework (Identify, Protect, Detect, Respond, Recover) for managing cybersecurity risk at any scale. | Gap assessment against CSF tiers; sector-specific profiles |
| 769 | COBIT | Governance framework aligning IT controls, assurance, and business objectives with management and technical layers. | Board-level oversight of IT security investment and controls |
| 770 | ITIL | Service management framework covering incident, change, problem, and service processes that support security operations. | Change Advisory Board process before production changes |
| 771 | Security governance | Oversight structure assigning ownership, approving policy, and tracking accountability for security decisions at all levels. | Security steering committee reviews risk register quarterly |
| 772 | Security compliance | Demonstrating that security requirements from laws, standards, contracts, or internal policy are being met with evidence. | Control attestations, evidence packages, audit readiness |
| 773 | Regulatory compliance | Satisfying obligations imposed by statutory bodies or government regulators specific to an industry or jurisdiction. | Financial services: FCA rules; Healthcare: CQC/CMS oversight |
| 774 | Risk management framework | Structured process for identifying, assessing, treating, monitoring, and reporting on risk across an organization. | NIST RMF (categorize→select→implement→assess→authorize→monitor) |
| 775 | Audit requirements | Evidence and process expectations that must be satisfied during internal or external security and compliance audits. | Log retention, policy records signed off annually, control testing |
| 776 | Security policies | High-level mandatory rules defining expected behavior, accountability, and control objectives — signed by leadership. | Acceptable use policy, password policy, remote access policy |
| 777 | Security procedures | Step-by-step operational instructions showing how staff carry out policy requirements in practice. | User offboarding checklist, incident escalation procedure |
| 778 | Security guidelines | Recommended practices helping teams apply policy without always being mandatory — provide flexibility. | Secure coding guideline, mobile device configuration guide |
| 779 | Security standards | Baseline technical or process requirements all systems must meet — more specific than policies. | CIS Benchmarks, enterprise hardening baseline (e.g., Windows 10 L1) |
| 780 | Legal compliance | Operating in full accordance with applicable laws, regulations, and contractual obligations with documented evidence. | Controls mapped to legal obligations in a compliance register |
Compliance and Enforcement (781–800)
| # | Concept | Interview Answer | Example / Reference |
|---|---|---|---|
| 781 | Data privacy protection | Controls and legal practices keeping personal data confidential, lawful, and limited to its stated collection purpose. | Consent management platform, retention limits, privacy-by-default |
| 782 | Data classification | Mandatory categorization of data by sensitivity and regulatory status to determine handling requirements. | Public / Internal / Confidential / Restricted classification scheme |
| 783 | Data retention law | Rules defining how long specific records must be kept and when they must be securely deleted. | Tax records: 7 years; healthcare: varies by jurisdiction |
| 784 | Data transfer law | Legal restrictions and safeguards that apply when data is shared with a third party, processor, or another country. | Data Processing Agreements (DPAs), Standard Contractual Clauses |
| 785 | Cross-border data transfer | Sending personal data across national borders where each country may have different protection requirements. | EU-US Data Privacy Framework, SCCs for GDPR transfers outside EEA |
| 786 | Cyber liability | Legal and financial exposure an organization faces after security failures, privacy violations, or service disruption. | Cyber insurance policy, contractual indemnity clauses |
| 787 | Legal risk management | Identifying, tracking, and reducing legal exposure tied to security decisions, data handling, and breach scenarios. | Legal review of incident response plan; breach simulation with counsel |
| 788 | Incident reporting law | Laws or sector rules requiring certain incidents to be formally reported to regulators or affected individuals within defined windows. | GDPR: 72 hours to supervisory authority; US: state-specific timelines |
| 789 | Digital evidence law | Rules governing how electronic evidence is collected, preserved, authenticated, and presented to remain admissible in court. | Forensic imaging with hash verification and documented chain of custody |
| 790 | Cyber forensics law | Legal requirements governing cyber investigations including evidence handling, examiner authority, and lawful access. | Search warrant scope for device seizure; ACPO principles (UK) |
| 791 | Ethical hacking law | Legal boundaries for authorized security testing — requires explicit written authorization and defined scope. | Signed rules of engagement and statement of work before any test |
| 792 | Penetration testing law | Legal and contractual rules determining what testing is allowed, on what systems, and with whose written consent. | Cloud provider permission (AWS pen-test policy) before testing |
| 793 | Bug bounty policy | Published program terms defining what researchers may test, how to report vulnerabilities, and what safe harbor applies. | HackerOne or Bugcrowd program policies; in-scope asset definitions |
| 794 | Responsible disclosure | The practice of reporting vulnerabilities privately to the owner and giving them time to patch before public disclosure. | 90-day disclosure deadline standard (Google Project Zero) |
| 795 | Security audit compliance | Meeting all audit expectations for control documentation, evidence, and remediation tracking within required timelines. | Passing ISO 27001 surveillance audit or SOC 2 Type II examination |
| 796 | Third-party compliance | Verifying that vendors and partners also meet the security and privacy obligations required by your organization or regulators. | Annual vendor security questionnaires, right-to-audit clauses |
| 797 | Vendor risk compliance | Applying compliance and risk requirements to suppliers that process your data or provide critical services. | Security clauses in procurement contracts; vendor tier risk ratings |
| 798 | Security certification | Formal recognition that a person, process, or product has met a defined security standard through independent assessment. | ISO 27001 cert, SOC 2 report, CISSP certification |
| 799 | Compliance monitoring | Ongoing review confirming controls continue to meet legal, regulatory, and contractual duties between formal audits. | Continuous control monitoring dashboard; quarterly self-assessments |
| 800 | Legal enforcement | Actions taken by regulators, courts, or counterparties when security or privacy obligations are violated. | GDPR fines (up to 4% global turnover), FTC enforcement orders |
Interview Questions & Answers
Q1. What is GDPR and what are its key obligations for a security team?
"GDPR — the General Data Protection Regulation — is the EU's comprehensive data protection law that came into force in May 2018. It applies to any organization processing personal data of EU residents, regardless of where the organization is based. From a security team perspective, the key obligations are: implementing appropriate technical and organizational measures to protect personal data; notifying the supervisory authority of a data breach within 72 hours of becoming aware of it; notifying affected individuals without undue delay if the breach poses a high risk to their rights and freedoms; conducting Data Protection Impact Assessments (DPIAs) for high-risk processing; and appointing a Data Protection Officer where required. GDPR fines can reach €20 million or 4% of global annual turnover — whichever is higher."
Q2. What is the difference between HIPAA and GDPR?
"HIPAA is a US federal law specifically protecting Protected Health Information (PHI) in the healthcare sector — it applies to covered entities (hospitals, providers, insurers) and their business associates. GDPR is the EU's broad data protection regulation applying to personal data of any EU resident across all sectors. Key differences: HIPAA is sector-specific (healthcare only); GDPR is universal. HIPAA doesn't require breach notification to individuals for all breaches — only if PHI is unsecured and the probability of compromise is significant. GDPR requires a 72-hour authority notification for any personal data breach meeting the threshold. GDPR has explicit requirements for consent and data subject rights that HIPAA doesn't mirror."
Q3. What is PCI DSS and what are its 12 requirements?
"PCI DSS — Payment Card Industry Data Security Standard — is a mandatory security standard for any organization that stores, processes, or transmits cardholder data. The 12 requirements are grouped under 6 goals: Build and maintain a secure network (firewalls, no vendor defaults); Protect cardholder data (encryption, tokenization, masking); Maintain a vulnerability management program (AV, secure software development); Implement strong access control measures (least privilege, MFA, physical access); Regularly monitor and test networks (logging, penetration testing); Maintain an information security policy. Non-compliance risks include card brand fines, increased transaction fees, and ultimately losing the ability to process card payments."
Q4. What is ISO 27001 and how does it differ from ISO 27002?
"ISO 27001 is the certification standard — it specifies the requirements for establishing, implementing, maintaining, and continuously improving an Information Security Management System (ISMS). Organizations can be certified against ISO 27001 through an accredited certification audit. ISO 27002 is the companion code of practice — it provides detailed implementation guidance for the 93 controls listed in Annex A of ISO 27001. ISO 27001 tells you what you must do; ISO 27002 tells you how to do it. An organization uses ISO 27001 to build the ISMS framework and risk-based control selection, while ISO 27002 provides the implementation detail for each control."
Q5. What is the NIST Cybersecurity Framework (CSF)?
"The NIST CSF is a voluntary, risk-based framework created by the US National Institute of Standards and Technology for managing cybersecurity risk. It organizes activities into five core functions: Identify (know your assets, risks, and environment), Protect (implement safeguards), Detect (identify cybersecurity events), Respond (take action when an event is detected), and Recover (restore capabilities after an incident). The framework is sector-agnostic and scalable — it's used by organizations from SMBs to critical national infrastructure. Each function maps to categories and subcategories with informative references to other standards like ISO 27001, COBIT, and CIS Controls."
Q6. What is the NIST RMF (Risk Management Framework)?
"The NIST RMF is a structured process for integrating security and risk management into the system development lifecycle. It has six steps: Categorize the system (identify information types and impact levels); Select controls (choose appropriate baseline controls for the category); Implement controls (deploy and document the selected controls); Assess controls (independently verify controls are correctly implemented and effective); Authorize the system (senior official accepts the residual risk); Monitor controls (continuously monitor, report on, and update security posture). The RMF is mandatory for US federal agencies and is increasingly adopted in the private sector as a rigorous risk-based approach."
Q7. What is responsible disclosure and what is the 90-day deadline?
"Responsible disclosure is the security research practice of privately reporting a discovered vulnerability to the affected organization before making it public, giving them time to develop and deploy a fix. The 90-day deadline was popularized by Google's Project Zero team — they notify vendors of discovered vulnerabilities and give 90 days to release a patch before publishing technical details publicly, regardless of whether a fix is ready. This approach balances giving vendors reasonable time to fix while creating accountability and pressure to patch promptly — without a deadline, organizations sometimes deprioritize patches indefinitely."
Q8. What legal authorization is required before a penetration test?
"A penetration test requires explicit written authorization from the system owner before any testing begins. This authorization document — commonly called a Statement of Work (SOW) plus Rules of Engagement (RoE) — must define: the scope of systems that may be tested, the testing methods permitted, the dates and time windows for testing, emergency contact procedures, and explicit permission to perform otherwise illegal activities (unauthorized access is a criminal offense without this authorization). Testing cloud environments requires additional permission from the cloud provider — AWS, Azure, and GCP all have separate penetration testing policies that must be followed."
Q9. What is a Data Protection Officer (DPO) and when is one required?
"A Data Protection Officer is a role mandated under GDPR for organizations that process personal data at scale or handle sensitive data categories. A DPO is required for: public authorities and bodies; organizations conducting large-scale systematic monitoring of individuals (e.g., ad-tech, tracking companies); and organizations processing special categories of data (health, biometrics, religion, political opinions) on a large scale. The DPO operates independently, cannot be instructed about their duties, advises on DPIA obligations, monitors compliance, and acts as the point of contact with data protection authorities. The DPO is there to ensure the organization meets its GDPR obligations, not to cover up non-compliance."
Q10. What is a Data Processing Agreement (DPA) and when is it required?
"Under GDPR Article 28, when a data controller uses a data processor (a third party that processes personal data on the controller's behalf), a written Data Processing Agreement must be in place. The DPA binds the processor to specific obligations: process data only on the controller's documented instructions; ensure people with access to data are under confidentiality obligations; implement appropriate security measures; assist the controller with breach notification and DSAR responses; delete or return all data after service ends; and allow audits. This means every organization must have DPAs in place with cloud providers, SaaS vendors, payroll processors, and any other third party that handles personal data."
Q11. What is the difference between a regulation, a standard, and a framework?
"A regulation is legally binding — created by a government or regulatory authority and enforceable through fines, penalties, or criminal prosecution. GDPR, HIPAA, and PCI DSS (where required by contracts) are enforced in law. A standard is a defined set of requirements or controls — often created by industry or standards bodies like ISO or NIST — that organizations can be certified or measured against. Standards are often not directly legally binding but may be contractually required. A framework is a structured set of guidance and best practices providing a common language and approach — like NIST CSF — typically voluntary, flexible, and not audited for certification."
Q12. What is SOC 2 and how does it differ from ISO 27001?
"SOC 2 — Service Organization Control 2 — is an auditing standard developed by the AICPA for service providers storing customer data in the cloud. It assesses controls against the Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. A SOC 2 Type I report assesses whether controls are suitably designed at a point in time. A Type II report covers a period (usually 6–12 months) and tests whether controls operated effectively throughout. ISO 27001 is an internationally recognized certification requiring a formal ISMS. SOC 2 is more common in North America (especially for SaaS vendors asked by enterprise customers); ISO 27001 is more common in Europe and globally. Both demonstrate security maturity but through different lenses."
Q13. What is the Computer Fraud and Abuse Act (CFAA)?
"The CFAA is a US federal law that criminalizes unauthorized access to computer systems. It's the primary statute used to prosecute cybercrime in the United States. 'Unauthorized access' under the CFAA has been controversial — early interpretations included violating terms of service on a computer you were authorized to use. The CFAA is the reason that penetration testers must obtain explicit written authorization before any testing — without it, their activities could be prosecuted as unauthorized access even if no damage was intended. The CFAA is also relevant to bug bounty participants — a program's safe harbor clause provides explicit authorization to test within defined scope."
Q14. What is a DPIA (Data Protection Impact Assessment)?
"A DPIA — Data Protection Impact Assessment — is a process required by GDPR (Article 35) for processing activities likely to result in high risk to individuals' rights and freedoms. When must you do one? When processing involves systematic and extensive automated decision-making or profiling; large-scale processing of special category data; or systematic monitoring of a publicly accessible area. The DPIA process involves: describing the processing purpose and necessity; assessing necessity and proportionality; identifying and assessing risks to individuals; and identifying measures to mitigate those risks. DPIAs must be carried out before the processing begins, not after."
Q15. What is the 72-hour breach notification rule under GDPR?
"Under GDPR Article 33, when a data controller becomes aware of a personal data breach that is likely to result in a risk to individuals' rights and freedoms, they must notify the relevant supervisory authority within 72 hours. If notification is not possible within 72 hours, a partial notification must be made with the reasons for the delay and additional information provided as soon as possible. If the breach is unlikely to result in risk — for example, because the data was encrypted with a strong key that wasn't disclosed — notification may not be required. Controllers must also directly notify affected individuals without undue delay if the breach is likely to result in a high risk to those individuals."
Key Laws & Standards at a Glance
| Law / Standard | Who It Applies To | Enforcer | Key Penalty |
|---|---|---|---|
| GDPR | Any org with EU personal data | National DPA (e.g., ICO, CNIL) | €20M or 4% global turnover |
| HIPAA | US healthcare covered entities + BAs | HHS Office for Civil Rights | Up to $1.9M per violation type/year |
| PCI DSS | Card data handlers globally | Card brands (Visa, Mastercard) | Fines + loss of card acceptance |
| CFAA | US computer systems | US DOJ | Criminal prosecution, prison |
| CCPA | Orgs handling CA residents' data | CA Attorney General | $7,500 per intentional violation |
| ISO 27001 | Voluntary — any organization | Accredited certification bodies | Loss of certification |
| NIST CSF | Voluntary — US critical infra focus | CISA (guidance, not enforcement) | N/A (voluntary) |
| SOC 2 | Cloud/SaaS service orgs | AICPA-licensed CPA firms | Loss of attestation report |
Common Exam / Interview Traps
- GDPR 72 hours is notification to the supervisory authority — not to customers (that's "without undue delay" and only for high-risk breaches)
- PCI DSS is not a law — it's a contractual standard enforced by card brands via merchant agreements
- ISO 27001 certifies the ISMS process — not individual controls; ISO 27002 provides the control guidance
- NIST CSF is voluntary in the US — though some sectors (energy, finance) have regulatory expectations to align with it