1.4 Law, Compliance & Privacy
Law, Compliance & Privacy at a glance
Cybersecurity does not operate in isolation. Organisations must protect information while complying with laws, regulations, contractual obligations, industry requirements and privacy expectations.
Security professionals do not need to be lawyers, but they do need to recognise when legal or compliance requirements affect security decisions and when specialist legal advice is required.
Law & Regulation
Understand which legal and regulatory requirements apply.
What MUST we do?Compliance
Demonstrate that required controls and processes are actually being followed.
Can we PROVE it?Privacy
Handle personal information lawfully, fairly and appropriately.
Should we USE this data?Laws vary between jurisdictions and change over time. This lesson explains concepts relevant to CISSP study and security practice; it is not legal advice.
Where legal interpretation is required, organisations should involve appropriately qualified legal, privacy or compliance professionals.
Understanding the compliance landscape
Security requirements can originate from several different sources. One of the most important skills is identifying what type of requirement you are dealing with.
| Source | Meaning | Example |
|---|---|---|
| Law | Legislation establishing legally enforceable requirements. | Data protection or cybercrime legislation |
| Regulation | Detailed requirements created or enforced by an authorised regulatory body. | Sector-specific regulatory requirements |
| Contract | Legally binding obligations agreed between parties. | Security requirements in a supplier contract |
| Industry Standard | A recognised set of requirements or practices which may become mandatory through contract, regulation or business participation. | PCI DSS |
| Internal Policy | Requirements established by the organisation itself. | Corporate information security policy |
Something does not need to be a law to create a mandatory security requirement.
A contractual obligation, regulatory rule or industry requirement may still require the organisation to implement particular controls.
1 Jurisdiction Which laws apply?
Why jurisdiction matters
Organisations operating across multiple countries can be subject to several different legal systems at the same time.
Relevant factors may include:
Cloud computing makes jurisdiction particularly interesting because information may be processed or stored across several locations.
A company headquartered in one country operates a cloud platform hosted in another country and processes information belonging to customers located across several additional jurisdictions.
Multiple legal and regulatory requirements may therefore need to be considered.A security professional should recognise potential jurisdictional issues and involve appropriate legal expertise rather than attempting to personally interpret complex international law.
2 Cybercrime When computer activity becomes a legal issue
What is cybercrime?
Cybercrime broadly refers to criminal activity involving computers, networks, digital systems or information.
Exact offences and definitions vary by jurisdiction, but common categories include:
Accessing systems or accounts without appropriate authority.
Creating, deploying or using malicious software in prohibited ways.
Using computer systems to obtain money, information or services dishonestly.
Unlawfully intercepting communications or network traffic.
Destroying, altering or damaging information without authority.
Using threats such as ransomware or data disclosure to demand payment.
Authorisation is critical
Many legitimate cybersecurity activities resemble techniques used by attackers.
Penetration testing may involve:
The key difference is that legitimate testing is performed with appropriate authority and within an agreed scope.
A penetration tester is authorised to test 10.20.30.0/24.
During reconnaissance they discover an interesting server on another network.
The server should not simply be tested because it is technically reachable. The tester must remain within the authorised scope.Capability ≠ Authorisation.
3 Privacy and Data Protection Security is necessary, but privacy goes further
Security vs privacy
Security and privacy overlap, but they are not identical.
Protects information and systems from threats such as unauthorised access, modification and loss.
Concerns whether personal information is collected, used, shared, retained and otherwise processed appropriately.
A company collects detailed location data from every customer and stores it inside a strongly encrypted database.
The database may be technically secure.
But there may still be a privacy issue if the organisation has no legitimate reason to collect or retain that information.Security asks: Is the data protected?
Privacy asks: Should we have and use the data in this way in the first place?
4 GDPR A major privacy framework for CISSP study
General Data Protection Regulation
The General Data Protection Regulation (GDPR) establishes requirements for the processing and protection of personal data in the European Union and European Economic Area.
Its relevance extends beyond cybersecurity because it governs how organisations collect, use, store, share and protect personal data.
Personal data
Personal data is information relating to an identified or identifiable natural person.
Depending on the circumstances, examples may include:
Controller vs Processor
Determines the purposes and means of processing personal data.
Think: Why and how?
Processes personal data on behalf of the controller.
Think: Acts for the controller.
A retailer decides which customer information it needs and why.
It uses an external cloud provider to process that information on its behalf.
The retailer may be the controller and the service provider may act as a processor, depending on the actual processing arrangement.
🧭 The GDPR Data Protection Principles A useful privacy decision framework
The GDPR establishes fundamental principles for processing personal information.
Processing should have a lawful basis, treat people fairly and be sufficiently transparent.
Personal data should be collected for specified and legitimate purposes.
Collect only the personal data that is appropriate and necessary for the intended purpose.
Personal information should be accurate and appropriately kept up to date.
Do not retain identifiable personal information indefinitely without justification.
Protect personal information through appropriate security.
Organisations must take responsibility for compliance and be able to demonstrate it.
Only one principle explicitly focuses on information security.
Privacy therefore involves much more than simply encrypting data and controlling access.
📋 Lawful bases for processing Consent is not the only option
Under the EU GDPR, organisations need an appropriate lawful basis when processing personal information.
The individual has given valid consent.
Processing is necessary for a contract involving the individual.
Processing is required to comply with a legal obligation.
Processing is necessary to protect someone's vital interests.
Processing is necessary for an appropriate task in the public interest or official authority.
Processing may be justified by legitimate interests where the relevant legal requirements are satisfied.
GDPR does not mean that organisations must obtain consent for every use of personal data.
👤 Individual privacy rights People may have rights over information about them
Privacy legislation may give individuals various rights over their personal information.
Under GDPR, these can include rights relating to:
An organisation cannot respond effectively to an access or deletion request if it does not know where personal data is stored.
Privacy therefore depends on good data governance, inventory, classification and access-control practices.🏗️ Privacy by Design and by Default Build privacy into systems early
Privacy requirements should be considered when systems and processes are designed rather than being added only after deployment.
Useful design questions include:
Avoid collecting unnecessary personal information.
Apply appropriate access control and least privilege.
Establish appropriate retention and deletion rules.
Consider techniques such as pseudonymisation or anonymisation where appropriate.
Design processes capable of locating, correcting, exporting or deleting relevant information where legally required.
Consider encryption, authentication, monitoring, segregation and other appropriate security controls.
🌍 Privacy laws around the world There is no single global privacy law
Privacy legislation differs across jurisdictions.
The CISSP exam outline gives examples including:
🇪🇺 GDPR
The General Data Protection Regulation is a major European data protection regime governing the processing of personal data.
🇺🇸 CCPA
The California Consumer Privacy Act gives qualifying California consumers rights concerning personal information held by covered businesses.
These include rights relating to knowing, deleting, correcting and controlling certain uses or sharing of personal information.
🇨🇳 PIPL
China's Personal Information Protection Law is another major example of jurisdiction-specific privacy legislation referenced by ISC2.
🇿🇦 POPIA
South Africa's Protection of Personal Information Act provides another example of a national privacy regime referenced in the CISSP exam outline.
The important CISSP concept is that organisations must identify the privacy laws applicable to their particular processing activities, jurisdictions and data subjects.
🏥 Sector-specific privacy and security HIPAA as an example
Some legal requirements apply specifically to particular sectors or categories of information.
HIPAA
In the United States, HIPAA provides an important example involving health information.
Establishes protections relating to protected health information and limits how covered information may be used and disclosed.
Establishes administrative, physical and technical safeguards for electronic protected health information.
Regulations may be both jurisdiction-specific and industry-specific.
5 Data breaches and notification A security incident can trigger legal obligations
Security incidents can become legal events
A breach may trigger requirements beyond technical incident response.
Depending on the applicable law, organisations may need to consider:
GDPR example
Under the EU GDPR, where the legal threshold for notification is met, a controller must notify the appropriate supervisory authority without undue delay and, where feasible, no later than 72 hours after becoming aware of the breach.
Notification to the supervisory authority is not required where the breach is unlikely to result in a risk to people's rights and freedoms.
Where a breach is likely to result in a high risk to individuals, communication to affected individuals may also be required.
Do not automatically assume that every security event must be publicly disclosed immediately.
Notification depends on the applicable legal, regulatory and contractual requirements and the facts of the incident.
Security response and legal response work together
Understand what happened.
Limit ongoing damage.
Determine the systems, information and individuals affected.
Legal, privacy, compliance, incident response and communications teams may all need to participate.
Identify relevant regulatory, legal and contractual requirements.
Maintain appropriate records of the incident and the organisation's response.
6 Intellectual Property Protecting creations, inventions and business information
What is Intellectual Property?
Intellectual Property (IP) concerns legally protected creations and intangible assets.
Cybersecurity professionals may encounter IP when protecting source code, inventions, product designs, documentation, algorithms and confidential business information.
Protects rights relating to creative works, which can include computer programs and documentation.
Think: Expression.
Provides legal protection for qualifying inventions.
Think: Invention.
Protects signs used to distinguish goods or services, such as names or branding.
Think: Brand.
Protects valuable confidential information when appropriate steps are taken to maintain its secrecy.
Think: Secret business knowledge.
Trade secrets and security
Trade-secret protection is particularly relevant to cybersecurity because maintaining confidentiality can be essential to the protection.
Controls may include:
A company develops a valuable proprietary manufacturing process and treats the details as confidential.
Only a small group of employees has access, documents are classified, technical restrictions are applied and confidentiality agreements are used.
Security controls can therefore play an important role in protecting intellectual property.Intellectual Property memory aid
Expression. Invention. Brand. Secret.
📄 Software licensing Permission to use does not mean ownership
Organisations frequently use software they do not own.
A licence defines the conditions under which software or other intellectual property may be used.
Buying or downloading software does not necessarily transfer ownership of its intellectual property.
The user may instead receive specific rights defined by a licence.
Security and compliance concerns
- using software beyond permitted licence terms;
- installing unlicensed software;
- copying proprietary source code;
- failing to understand open-source licence obligations;
- redistributing components without appropriate rights;
- using third-party libraries without tracking their licences.
A development team copies an external software library into a commercial application.
The library appears to be freely available online.
The organisation should still understand the applicable licence and its obligations before distributing the resulting product.Software Composition Analysis and Software Bills of Materials can also help organisations identify third-party components and dependencies.
7 Import and Export Controls Security technology may be regulated
Governments may restrict the export, import or transfer of certain technologies.
Depending on the jurisdiction and technology, controls can potentially affect areas such as:
Why encryption appears in this topic
Cryptographic technology historically has been subject to export restrictions in various jurisdictions.
For example, US Export Administration Regulations contain provisions relating to certain encryption software and technology.
A company develops a security product containing advanced encryption and plans to distribute it internationally.
The organisation should determine whether any relevant export-control obligations apply rather than assuming that digital distribution is legally equivalent everywhere.You are generally expected to recognise that import/export controls may affect security products and cryptography — not to become an export-control lawyer.
8 Transborder Data Flow Moving information across jurisdictions
What is transborder data flow?
Transborder data flow refers to information moving between different national or legal jurisdictions.
This can occur when:
- data is transferred to an overseas supplier;
- cloud information is stored in another country;
- employees access information from abroad;
- international business units share customer records;
- a global security team accesses logs from another jurisdiction.
Why this creates risk
Different countries may have different rules concerning:
UK example
Under the UK GDPR framework, certain transfers of personal information outside the UK are treated as restricted transfers.
Depending on the circumstances, an appropriate mechanism may involve:
The destination is covered by appropriate UK adequacy arrangements.
Approved safeguards are used for the transfer.
A legally recognised exception applies in appropriate circumstances.
A UK company purchases a SaaS service from a global supplier.
The application processes employee information and stores backups in another jurisdiction.
The organisation should understand where the information goes and whether the transfer creates additional legal requirements.Encrypting information in transit protects security, but encryption alone does not automatically satisfy every legal requirement governing international data transfers.
9 Contractual Security Requirements Contracts can create mandatory security obligations
Security requirements are frequently established through contracts with customers, suppliers and business partners.
Common contractual provisions may address:
Minimum technical and organisational security requirements.
When and how one party must inform another of an incident.
Rules governing how information may be used.
Ability to obtain assurance or inspect compliance.
Requirements governing downstream suppliers.
Restrictions concerning where information may be processed.
Requirements for retaining, returning or deleting information.
Availability, recovery or performance obligations.
A contract requires a supplier to notify the customer of a security incident within 24 hours.
Applicable privacy legislation might allow a different regulatory notification timeframe.
The organisation must consider both requirements. The contractual requirement does not disappear simply because the law provides a different deadline.⏱️ Service Level Agreements Defining measurable service expectations
A Service Level Agreement (SLA) defines measurable expectations for a service.
Security-related SLA requirements might include:
A cloud provider commits to a defined monthly availability level.
The organisation should understand what happens if that service level is not achieved and whether the commitment actually meets the organisation's business requirements.
🏭 Industry standards and compliance Not every mandatory requirement comes directly from government
PCI DSS example
PCI DSS establishes security requirements relating to environments that handle payment-card information.
It is an important example of a security requirement that should not simply be described as a government law.
PCI DSS is an industry security standard, not itself a piece of government legislation.
However, organisations may still be contractually required to comply with it.
Compliance obligations can overlap
An online healthcare company accepts payment cards.
Its environment could potentially be subject to privacy requirements, healthcare requirements, contractual commitments and payment-card security standards simultaneously.
Organisations therefore need a holistic view of their obligations.10 Managing Compliance Knowing a requirement exists is only the beginning
Organisations need processes for identifying, implementing and demonstrating compliance requirements.
Determine which laws, regulations, contracts and standards apply.
Understand what those obligations require from the organisation.
Determine which security and business controls satisfy the requirements.
Put appropriate technical, physical and administrative measures into operation.
Maintain documentation and evidence demonstrating how requirements are being met.
Test whether controls continue to operate effectively.
Address identified weaknesses or compliance gaps.
Monitor changes in laws, technology, business activity and contractual obligations.
Security vs Compliance
Security and compliance support each other, but they are not the same.
🛡️ Compliance does not automatically mean secure A critical security principle
An organisation may successfully satisfy a particular compliance requirement and still have serious security weaknesses.
Compliance generally demonstrates that specific requirements have been addressed.
Security must also consider:
An organisation completes an annual compliance assessment in January.
In March, a new critical vulnerability appears in one of its internet-facing products.
Passing the January assessment does not mean the organisation remains secure against the new threat.Compliance can support security.
Compliance should not become a substitute for risk management.
⚠️ Common mistakes Easy legal and privacy concepts to confuse
Compliance addresses defined obligations. Security requires ongoing management of real-world risk.
Consent is only one possible lawful basis under the EU GDPR.
Encryption protects information, but privacy also concerns whether collection, use, retention and sharing are appropriate.
PCI DSS is an industry standard, although compliance obligations may arise through contractual relationships.
The 72-hour concept is associated with particular GDPR regulatory notification requirements. Different laws, contracts and incidents can have different requirements.
Outsourcing processing does not automatically remove an organisation's own legal or regulatory responsibilities.
Open-source software is distributed under licences whose conditions should be understood and respected.
Technical access does not automatically establish legal authority or an approved penetration-testing scope.
Think beyond the technical control
Questions in this area often test whether you recognise that a security issue can also involve legal, privacy, contractual or regulatory obligations.
⚖️ Legal clues
🔐 Privacy clues
✅ Compliance clues
📝 Practice scenarios Apply legal, compliance and privacy thinking
Scenario 1 — Too much customer data
An application collects customer dates of birth, home addresses and precise location information even though none of these are required to provide the service.
Primary concern:
Privacy principles such as data minimisation and purpose limitation should be considered.
Scenario 2 — Security testing outside scope
A tester identifies an interesting server belonging to the client but outside the written penetration-test scope.
Best response:
Stop and obtain appropriate authorisation before testing it.
Scenario 3 — Overseas cloud storage
A company discovers that its SaaS provider stores customer records in several countries that were never considered during procurement.
What should be assessed?
Data-location, contractual, jurisdictional and international-transfer requirements.
Scenario 4 — Data breach
Customer personal information is accidentally made publicly accessible.
What should happen?
Contain and investigate the incident while promptly involving appropriate privacy, legal and compliance specialists to determine applicable notification obligations.
Scenario 5 — Contract vs regulation
A supplier contract requires incident notification within 12 hours. A relevant regulatory regime specifies a different notification timeframe.
What matters?
The organisation should identify and satisfy all applicable obligations rather than assuming one automatically replaces another.
Scenario 6 — Passing an audit
An organisation recently passed a compliance audit but discovers a newly exploited critical vulnerability.
Best response:
Assess and treat the current security risk. Previous compliance does not remove the need to respond to new threats.
Scenario 7 — Free code from the internet
A developer finds source code online and wants to include it in a commercial product.
What should be checked?
Copyright ownership and applicable software licence terms should be understood before reuse or distribution.
Quick memory aid
Identify. Understand. Protect. Demonstrate.
GDPR principles memory aid
Key takeaways
Cybersecurity professionals must understand the legal and regulatory environment in which security operates.
Laws vary by jurisdiction, and multinational organisations may need to consider several legal regimes simultaneously.
Privacy and security overlap, but they are not the same. Security protects information; privacy also concerns whether personal information should be collected, used, shared and retained in a particular way.
GDPR introduces important concepts including controllers, processors, processing principles, lawful bases, individual rights and breach notification requirements.
Consent is not the only GDPR lawful basis.
Intellectual property can include copyrights, patents, trademarks and trade secrets, and security controls can play an important role in protecting valuable IP.
Software licensing defines how software may legally be used and distributed.
Import and export controls can affect cryptography and certain security technologies.
International data transfers can introduce additional legal and privacy requirements.
Contracts can create security requirements independently of legislation.
Industry standards such as PCI DSS should not automatically be confused with government legislation.
Most importantly: compliance does not automatically mean secure. Effective security requires continuous risk management as threats, technologies and business requirements change.
📚 Sources & Further Reading Authoritative references for this lesson
CyberPrepHub lessons are designed as learning material rather than legal advice. For authoritative requirements, consult the relevant legislation, regulator or professional body.
- ISC2 — CISSP Certification Exam Outline
View official CISSP exam outline - European Union — General Data Protection Regulation
View GDPR on EUR-Lex - UK Information Commissioner's Office — Data Protection Principles
View ICO guidance - UK Information Commissioner's Office — International Transfers
View international transfer guidance - California Attorney General — California Consumer Privacy Act
View CCPA information - US Department of Health and Human Services — HIPAA
View HIPAA guidance - World Intellectual Property Organization
Learn about intellectual property - US Bureau of Industry and Security
View US Export Administration Regulations