Module 2: Core Legal Standards – Security-by-Design, Reasonable Security, and Accountability

Step 1 – Why these three standards matter everywhere

In Module 1 you mapped the global cybersecurity law landscape. This module zooms in on three core standards that appear again and again in different laws and guidance:

1. Security-by-design / privacy-by-design
2. Reasonable security / risk-based security
3. Accountability, governance, and documentation

Across very different regimes—like the EU GDPR (in force since 2018), NIS2 (adopted 2022, applies from October 2024), and the U.S. FTC Act Section 5 enforcement—regulators keep asking similar questions:

• Did you build security into the system from the start?
• Are your protections reasonable for your risks?
• Can you prove, with documentation and governance, that you did the right things?

Think of these three standards as a triangle:

• One side: design (security/privacy-by-design)
• One side: substance (reasonable, risk-based security)
• One side: proof (accountability and documentation)

This module helps you:

• Define each standard in legal-regulatory terms
• Compare how they show up in GDPR, NIS2, and U.S. FTC practice
• Translate them into internal policies, controls, and records you’d expect in an organization

Step 2 – Security-by-design and privacy-by-design in law

1. Core idea

Security-by-design means integrating security from the earliest stages of system and product development, not bolting it on at the end. Privacy-by-design applies the same idea to personal data and privacy risks.

2. Key legal anchors (as of early 2026)

• EU GDPR (since 2018)
• Art. 25 – Data protection by design and by default
• Controllers must implement appropriate technical and organizational measures (TOMs) both at the time of the determination of the means for processing and at the time of the processing itself.
• Examples: data minimization, pseudonymization, user-friendly privacy settings.
• Art. 32 – Security of processing connects design to actual security controls (confidentiality, integrity, availability, resilience).

• EU NIS2 Directive (adopted 2022, applies from Oct 2024)
• Focuses on essential and important entities (e.g., energy, transport, digital infrastructure).
• Requires “appropriate and proportionate technical, operational and organizational measures” for cybersecurity risk management, which must be integrated into governance and development (e.g., supply chain security, secure development practices).

• U.S. FTC Act Section 5 (unfair or deceptive practices)
• No single statute saying “security-by-design,” but FTC enforcement actions and orders effectively require it.
• The FTC criticizes companies that launch products without baseline protections or that ignore known security design flaws.
• Recent FTC orders often require secure software development life cycle (SSDLC) practices.

3. What security-by-design looks like in practice

Think of a software development lifecycle (SDLC) with built-in security checkpoints:

1. Requirements phase

• Identify data types, threat models, legal requirements (GDPR, sector laws).
• Decide on data minimization and access control before coding.

1. Design phase

• Use secure architecture patterns (e.g., layered defenses, least privilege).
• Choose privacy-enhancing techniques (pseudonymization, differential access).

1. Implementation phase

• Secure coding standards, code reviews, static analysis tools.
• Secrets management (no credentials in code repos).

1. Testing and deployment

• Security testing (penetration tests, fuzzing).
• Privacy impact assessments (e.g., GDPR DPIA when high risk to rights and freedoms).

1. Operations and maintenance

• Patch management, vulnerability disclosure policy.
• Logging, monitoring, and regular security reviews.

Legally, regulators don’t prescribe one methodology, but they expect documented, systematic security-by-design practices, not ad hoc fixes.

Step 3 – Example: Security-by-design vs. security-after-the-fact

Imagine a startup building a fitness tracking app that collects location and health data.

Scenario A – Security-after-the-fact (non-compliant behavior)

• The team rushes to launch with default public profiles.
• All data is stored unencrypted in a single cloud database.
• No access control model; all developers can query production data.
• Only after a security incident do they add encryption and restrict access.

Legal/regulatory view:

• Under GDPR Art. 25 & 32, this is problematic: they didn’t consider data protection by design or implement appropriate measures from the start.
• Under FTC Section 5, this could be seen as unreasonable security, especially if the company claimed to be “secure” in marketing.

Scenario B – Security-by-design (more compliant behavior)

• During requirements, they classify data as sensitive (health + location).
• They design role-based access control so only specific backend services can read raw data.
• They configure encryption in transit and at rest from day one.
• They set privacy-by-default: user profiles are private unless explicitly changed.
• Before launch, they perform a DPIA (GDPR context) and document risks and mitigations.

Legal/regulatory view:

• This aligns with security-by-design and privacy-by-design principles.
• If an incident still occurs, regulators will look at the documented process to judge whether the company acted responsibly.

The contrast shows that design decisions + documentation significantly influence legal exposure, even when both apps might suffer some vulnerabilities.

Step 4 – What is “reasonable security” and risk-based security?

1. Why laws use flexible terms

Most laws avoid listing a fixed set of security controls. Technology, threats, and best practices change too fast. Instead, they use phrases like:

• “Appropriate technical and organizational measures” (GDPR, NIS2)
• “Reasonable security procedures and practices” (common in U.S. state laws, e.g., California)
• “Reasonably designed” security programs (FTC settlements)

These terms all point to a risk-based approach: security should be proportionate to the risks created by your data, systems, and business model.

2. Key legal references

• GDPR Art. 32

Controllers and processors must ensure a level of security “appropriate to the risk”, considering:

• State of the art
• Implementation costs
• Nature, scope, context, and purposes of processing
• Risks to rights and freedoms of natural persons

• NIS2

Requires risk-management measures that are appropriate and proportionate. It lists areas like:

• Policies on risk analysis and information system security
• Incident handling
• Business continuity and crisis management
• Supply chain security
• Secure development and vulnerability handling

• U.S. FTC (Section 5)

The FTC evaluates whether a company’s practices are “reasonable” in context. Examples of unreasonable practices from past cases:

• Storing passwords in plain text
• Using default or hard-coded credentials
• Failing to patch known, exploitable vulnerabilities
• Collecting sensitive data without adequate access controls

3. Risk-based approach in practice

A simple 4-step risk-based approach:

1. Identify assets and data

• What systems and data are you protecting? (e.g., personal data, payment data, OT systems)

1. Assess threats and vulnerabilities

• Who might attack (insiders, criminals, state actors)?
• What weaknesses exist (unpatched servers, poor access control)?

1. Estimate impact and likelihood

• What happens if data is breached or systems go down?
• Consider legal, financial, operational, and human rights impacts.

1. Select controls proportionate to risk

• Higher risk → stronger controls (e.g., MFA, segmentation, encryption, formal incident response).
• Document why some controls were not adopted (cost, feasibility, alternative safeguards).

Regulators don’t require perfect security; they expect a defensible, well-documented risk-based program.

Step 5 – Thought exercise: Is this security “reasonable”?

Consider a small online bookstore that stores:

• Customer names and addresses
• Purchase history
• Hashed passwords
• No payment card data (outsourced to a PCI-compliant payment processor)

They currently:

• Use HTTPS for all traffic
• Store passwords using a modern hashing algorithm with salt
• Have daily backups, but backups are not encrypted
• Do not use multi-factor authentication (MFA) for admin accounts
• Patch servers irregularly, sometimes months late

Your task (reflect, maybe jot notes):

1. Which controls look reasonable for their risk profile?
2. Which practices are likely unreasonable, especially under GDPR Art. 32 or FTC standards?
3. If you had to fix two things first, what would they be and why?

Use these prompts:

• Risk to individuals: What could go wrong for customers?
• State of the art: Are there widely accepted, affordable best practices they’re ignoring?
• Documentation: How would you justify their current setup to a regulator after a breach?

You don’t need a single “correct” answer; the goal is to apply the risk-based reasoning regulators use.

Step 6 – Accountability, governance, and documentation

1. Accountability: the legal idea

Accountability means an organization must not only comply with the law, but also be able to demonstrate that compliance.

• Under GDPR (Art. 5(2)), the controller is responsible for, and must be able to demonstrate compliance with data protection principles.
• Under NIS2, management bodies (e.g., boards) have explicit responsibility and oversight duties; they can face sanctions for non-compliance.
• Under FTC practice, companies are expected to implement, monitor, and update security programs, and to keep records that show what they actually did.

2. Governance structures regulators look for

Common expectations across regimes:

• Clear roles and responsibilities
• Who is responsible for cybersecurity? (CISO, DPO, security lead)
• Who reports to the board or top management?

• Policies and procedures
• Written information security policy
• Access control policy
• Incident response plan
• Vendor / supply chain security policy

• Training and awareness
• Regular training for employees, tailored to roles.
• Records of who was trained and when.

• Monitoring and improvement
• Periodic risk assessments and audits
• Metrics and KPIs (e.g., patching timelines, phishing click rates)
• Management review and follow-up actions

3. Documentation duties (what to write down)

Examples of documents that show accountability:

• Risk assessments and DPIAs (where required)
• Records of processing activities (GDPR Art. 30)
• Security policies and standards
• Incident logs: what happened, detection, response, lessons learned
• Vendor due diligence records (questionnaires, contracts, security addenda)
• Board/management minutes discussing cybersecurity and approving budgets

From a legal perspective, “not written = didn’t happen”. Good documentation can significantly reduce regulatory penalties after an incident, because it shows you acted responsibly and systematically.

Step 7 – How these standards shape internal policies and controls

Let’s translate the three standards into concrete internal artifacts you’d expect to see in an organization.

1. Security-by-design → Development and product practices

• Secure SDLC policy
• Requires security requirements in design documents.
• Mandates threat modeling for new high-risk features.
• Requires security testing before production releases.

• Privacy-by-design guidelines
• Checklist for product teams: data minimization, default privacy settings, transparency.
• Template for Data Protection Impact Assessments (DPIAs).

2. Reasonable, risk-based security → Technical and organizational controls

• Access control and authentication standard
• MFA for admins and remote access.
• Role-based access control aligned with least privilege.

• Vulnerability and patch management procedure
• Timeframes: e.g., critical patches within 7 days.
• Documentation of exceptions and risk acceptance.

• Backup and recovery policy
• Frequency, encryption, and periodic restore tests.

3. Accountability → Governance and documentation

• Information Security Policy approved by top management.
• Formal assignment of roles (e.g., CISO, DPO, incident response lead).
• Training records and annual policy review logs.
• Incident response runbooks and after-action reports.

#### Visualizing it (text-based diagram)

```text

[Law/Regulation]

| (standards: security-by-design, reasonable security, accountability)

v

[Internal Governance]

• Policies (security, privacy, incident response)
• Roles (CISO, DPO, IT ops)
• Risk assessments & oversight

v

[Controls in Practice]

• Secure coding, MFA, logging, backups
• Vendor security, training, monitoring

v

[Documentation]

• Evidence that all of the above actually happens

```

When analyzing any security program, you can map each policy or control back to one or more of the three standards.

Step 8 – Quick check: Security-by-design vs. reasonable security

Answer this question to test your understanding of the distinction.

Step 9 – Quick check: Accountability in practice

Test your understanding of accountability and documentation.

Step 10 – Review key terms

Flip these cards (mentally or in notes) to reinforce the core concepts from this module.

Step 11 – Mini-application: Draft a one-paragraph policy snippet

To connect law to practice, draft a short policy snippet (4–6 sentences) for an imaginary company’s “Security-by-Design and Accountability Policy.”

Include at least:

1. A sentence committing to security-by-design (when in the lifecycle security must be considered).
2. A sentence about risk-based, reasonable security (how controls are chosen).
3. A sentence about accountability and documentation (records, reviews, responsibility).

Example structure (do NOT just copy; adapt in your own words):

> Our organization integrates security and privacy considerations into all stages of system and product development. We select and maintain technical and organizational measures proportionate to the risks associated with our data and services, taking into account state of the art and implementation costs. Responsibilities for cybersecurity and data protection are clearly assigned, and we maintain written records of risk assessments, design decisions, and security controls to demonstrate compliance with applicable laws.

Activity:

• Write your own version in your notes.
• Underline or highlight which sentence maps to security-by-design, which to reasonable security, and which to accountability.

This exercise mirrors what junior professionals often do in real organizations: turning abstract legal standards into clear, internal policy language.