🗺️ Big Picture
ISO 27001:2022 = International Standard for ISMS
│
├── Part I — What is ISMS? + Clauses 0–10 Structure
├── Part II — Gap Analysis, Risk Assessment, BIA, RTO/RPO
└── Part III — 93 Controls in 4 Themes
├── Organizational (5.x) — 37 controls
├── People (6.x) — 8 controls
├── Physical (7.x) — 14 controls
└── Technological (8.x) — 34 controls
Part I — Introduction to ISO 27001
Three Perspectives of Information Security
| Perspective | Focus |
|---|---|
| Business | How does InfoSec support business goals? |
| Customer (End User) | Data privacy and user rights |
| Service Provider / Supplier | Responsibilities in security assurance |
🍽️ Analogy: Like a restaurant — the owner (business) manages the operation, customers want their personal data safe, and the supplier must guarantee the quality of what they deliver.
What Is ISO/IEC 27001:2022?
- International standard for establishing an Information Security Management System (ISMS)
- Published by ISO (International Organization for Standardization) + IEC (International Electrotechnical Committee)
- Covers all organization types and sizes — commercial, government, non-profit
- Uses Plan–Do–Check–Act (PDCA) cycle for continuous improvement
🏭 Analogy: ISO 27001 is to information security what ISO 9001 is to quality management — a formal framework to prove you manage it properly.
Key Characteristics
- Concerns management of information security, not just technical IT security
- Implementation is scaled to the organization's size and needs
- Thousands of organizations worldwide are certified compliant
How to Protect Information (Tools)
Controls / Policy / Procedures / Passwords / Encryption / Security Applications / Secure Coding / Legal frameworks / Training & Awareness
ISO 27001 Clauses Structure
| Clause | Topic | PDCA Phase |
|---|---|---|
| 0 | Introduction | — |
| 1 | Scope | — |
| 2 | Normative references | — |
| 3 | Terms and definitions | — |
| 4 | Context of the organization | Plan |
| 5 | Leadership | Plan |
| 6 | Planning (risks + objectives) | Plan |
| 7 | Support (resources, awareness, docs) | Do |
| 8 | Operation (risk assessment + treatment) | Do |
| 9 | Performance evaluation (audit/review) | Check |
| 10 | Improvement (continuous improvement) | Act |
| Annex A | Controls reference (Statement of Applicability) | — |
Output of risk assessment → Assessment report → Apply controls to mitigate risks → Document in Statement of Applicability (SoA)
ISO 27001 Certification Path (12 Steps)
① Plan the project
② Define scope and context of ISMS
③ Obtain management commitment
④ Establish Information Security Policy
⑤ Set ISMS objectives + management system
⑥ Conduct Risk Assessment
⑦ Produce Statement of Applicability (SoA)
⑧ Implement controls
⑨ Internal audit
⑩ Management review
⑪ External audit — Stage 1
⑫ External audit — Stage 2 (Certification) ✅
Part II — Gap Analysis & Risk Assessment
Gap Analysis vs. Risk Assessment
| Gap Analysis | Risk Assessment | |
|---|---|---|
| Tells you | What you're missing to comply with ISO 27001 | What controls you should apply |
| Does NOT tell you | Which controls to apply to address identified risks | What controls you already have |
Gap Analysis = รู้ว่าขาดอะไร / Risk Assessment = รู้ว่าควรทำอะไร
What Is Risk?
| Term | Definition | Examples |
|---|---|---|
| Threat | Something that might cause harm | Fire, hacker, system failure |
| Vulnerability | Weakness that might be exploited | No backup, weak password, untrained staff |
| Impact | Resulting damage | Financial loss, reputational damage |
| Threat Agent | The actor behind the threat | Human / Machine / Nature |
Risk Relationship:
Threat Agent → exploits → Vulnerability → affects → Information Asset
↑
Controls reduce this
Goals of Risk Analysis
- Identify assets and their value to the organization
- Identify vulnerabilities and threats (via VAPT — Vulnerability Assessment & Penetration Testing)
- Quantify probability and business impact of threats
- Provide economic balance between impact and cost of countermeasure
Risk Assessment Process (NIST SP 800-30)
① Identify assets
② Identify vulnerabilities and threats
③ Assess business impact on each vulnerability/threat
④ Conduct Risk Analysis
⑤ Provide controls / treatment plan
⑥ Evaluate the controls
Risk Analysis Approaches
| Approach | Method | Output | Example |
|---|---|---|---|
| Quantitative | Monetary + numeric values assigned to all elements | "This risk will cost $50,000" | Asset value × threat frequency × vulnerability severity |
| Qualitative | Ratings based on expert judgment | Red/Yellow/Green or High/Medium/Low | Risk matrix |
Risk Calculation Methods
Detailed Risk Score:
Example (Laptop theft):
- Asset value = 3, Threat value = 2, Vulnerability value = 2 → Risk = 7
Qualitative Risk Matrix
| Likelihood ↓ \ Consequences → | Insignificant | Minor | Moderate | Major | Severe |
|---|---|---|---|---|---|
| Almost certain | M | H | H | E | E |
| Likely | M | M | H | H | E |
| Possible | L | M | M | H | E |
| Unlikely | L | M | M | M | H |
| Rare | L | L | M | M | H |
| Level | Color | Action Required |
|---|---|---|
| E — Extreme | 🔴 Red | Immediate action required |
| H — High | 🟠 Orange | Senior management attention needed |
| M — Medium | 🟡 Yellow | Management responsibility specified |
| L — Low | 🟢 Green | Manage by routine procedures |
Asset–Threat–Vulnerability Examples
| Asset | Threat | Vulnerability | CIA Impact |
|---|---|---|---|
| Paper document | Fire | No fire-proof cabinet | Loss of Availability |
| Paper document | Unauthorized access | Not locked | Loss of Confidentiality |
| Digital document | Disk failure | No backup | Loss of Availability |
| Digital document | Virus | Outdated antivirus | Loss of CIA |
| Digital document | Unauthorized access | Too many access rights | Loss of CIA |
| System administrator | Unavailability | No replacement person | Loss of Availability |
| System administrator | Frequent errors | Lack of training | Loss of Integrity + Availability |
Risk Treatment Options
| Option | What it means |
|---|---|
| Accept | Acknowledge and do nothing extra |
| Mitigate | Implement controls to reduce the risk |
| Transfer | Shift risk to a third party (e.g., insurance) |
| Avoid | Stop the activity that causes the risk |
Risk Acceptance Criteria
- Define a risk acceptance threshold (e.g., if scale is 2–10, define acceptable = 7)
- Only risks above threshold need treatment
- Must be formally defined and documented
Business Impact Analysis (BIA)
Determines the Maximum Acceptable Outage for each service.
| Question | 2 hrs | 4 hrs | 8 hrs | 24 hrs | 48 hrs | 1 week |
|---|---|---|---|---|---|---|
| Client reaction to disruption | 2 | 2 | 3 | 3 | 4 | 4 |
| Impact to other activities | 1 | 2 | 2 | 3 | 3 | 4 |
| Reputation damage | 1 | 2 | 2 | 3 | 4 | 4 |
| Backlog difficulty | 1 | 1 | 2 | 2 | 3 | 3 |
| Legal/contractual penalties (USD) | 0 | 1,000 | 2,000 | 30,000 | 60,000 | 210,000 |
| Revenue loss (USD) | 0 | 0 | 0 | 10,000 | 20,000 | 70,000 |
→ Maximum Acceptable Outage = between 8 and 24 hours → RTO is determined by examining dependencies on other activities
RTO & RPO
🕐 Analogy: RTO = "กลับมาทำงานได้ภายใน X ชั่วโมง" (how fast to recover). RPO = "ข้อมูลสูญหายได้ไม่เกิน X ชั่วโมงย้อนหลัง" (how much data can you afford to lose).
| RPO | Required Infrastructure |
|---|---|
| 1–2 days | Daily backup via network or cloud replication |
| 1–2 minutes | Mirrored disks |
Standby Types (determined by RTO):
- Cold standby — systems off, manual restart needed (longer RTO)
- Hot standby — systems running and ready (shorter RTO)
- Mirrored — real-time data mirroring (near-zero RTO/RPO)
⚠️ Key insight: Backup is NOT the real problem — being able to restore within the required timeframe is the real challenge.
Requirements for proper restore:
- Know the timeframe + order of system restoration
- Availability of systems + knowledgeable personnel + required software
- Restore procedures + test procedures post-restore
Part III — ISO/IEC 27002:2022 — 93 Controls in 4 Themes
| Theme | Section | Count |
|---|---|---|
| Organizational | Section 5 | 37 |
| People | Section 6 | 8 |
| Physical | Section 7 | 14 |
| Technological | Section 8 | 34 |
Control Attributes (5 Categories per control)
| Attribute | Values |
|---|---|
| Control type | Preventive, Detective, Corrective |
| InfoSec properties | Confidentiality, Integrity, Availability |
| Cybersecurity concepts | Identify, Protect, Detect, Respond, Recover |
| Operational capabilities | Governance, Asset mgmt, IAM, Threat mgmt, Continuity, etc. |
| Security domains | Governance & Ecosystem, Protection, Defense, Resilience |
3.1 Organizational Controls — Section 5 (37 controls)
Full List
| Control | Name |
|---|---|
| 5.1 | Policies for information security |
| 5.2 | Information security roles and responsibilities |
| 5.3 | Segregation of duties |
| 5.4 | Management responsibilities |
| 5.5 | Contact with authorities |
| 5.6 | Contact with special interest groups |
| 5.7 | Threat intelligence |
| 5.8 | Information security in project management |
| 5.9 | Inventory of information and other associated assets |
| 5.10 | Acceptable use of information and other associated assets |
| 5.11 | Return of assets |
| 5.12 | Classification of information |
| 5.13 | Labelling of information |
| 5.14 | Information transfer |
| 5.15 | Access control |
| 5.16 | Identity management |
| 5.17 | Authentication information |
| 5.18 | Access rights |
| 5.19 | Information security in supplier relationships |
| 5.20 | Addressing information security within supplier agreements |
| 5.21 | Managing information security in the ICT supply chain |
| 5.22 | Monitoring, review and change management of supplier services |
| 5.23 | Information security for use of cloud services |
| 5.24 | Information security incident management planning and preparation |
| 5.25 | Assessment and decision on information security events |
| 5.26 | Response to information security incidents |
| 5.27 | Learning from information security incidents |
| 5.28 | Collection of evidence |
| 5.29 | Information security during disruption |
| 5.30 | ICT readiness for business continuity |
| 5.31 | Legal, statutory, regulatory and contractual requirements |
| 5.32 | Intellectual property rights |
| 5.33 | Protection of records |
| 5.34 | Privacy and protection of PII |
| 5.35 | Independent review of information security |
| 5.36 | Compliance with policies, rules and standards |
| 5.37 | Documented operating procedures |
Key Organizational Controls — Details
5.1 — Policies for Information Security
- A document helping employees understand why InfoSec is important and what their role is
- Includes the information security policy + its review process
5.7 — Threat Intelligence
Three levels:
| Level | Audience | Content |
|---|---|---|
| Strategic | Executives | High-level trends and risk landscape |
| Tactical | Security teams | TTPs (Tactics, Techniques, Procedures) |
| Operational | SOC analysts | Specific IoCs for ongoing attacks |
Good threat intelligence must be: Relevant, Insightful, Contextual, Actionable
5.9 / 5.10 / 5.11 — Asset Management
- 5.9 Maintain an Asset Management DB (inventory of all assets)
- 5.10 Define Acceptable Use Policy for assets
- 5.11 Procedures for returning assets when employment ends
5.12 — Classification of Information ⭐ Exam Note
Q: What is the major benefit of information classification? A: We can apply/decide access controls appropriately for each class of information.
| Classification Level | Access |
|---|---|
| Highly Confidential | Only cleared individuals |
| Confidential | Restricted distribution |
| Public | Anyone |
- Asset owners classify information based on impact of loss/damage/disclosure
- Rules: e.g., confidential info must be encrypted or sent by registered mail
5.19–5.21 — Supplier Management
Supplier types: Software / Hardware / Facilities / BPO
| Access Level | Contract Type |
|---|---|
| Low access | Supplier Terms & Conditions (T&Cs) |
| High access | Full Contractual Agreement |
5.29–5.30 — Business Continuity (Availability)
- 5.29 — Security during disruption (BCM aspects) — continuity of security procedures during a crisis
- 5.30 — ICT readiness — redundancy of ICT services (servers, network, applications)
BCP requirements:
- Must be exercised periodically — must fully restore within RTO/RPO
- All personnel must know their roles
- Any organizational change must trigger BCP updates (via change management)
3.2 Physical Controls — Section 7 (14 controls)
Full List
| Control | Name |
|---|---|
| 7.1 | Physical security perimeters |
| 7.2 | Physical entry |
| 7.3 | Securing offices, rooms and facilities |
| 7.4 | Physical security monitoring |
| 7.5 | Protecting against physical and environmental threats |
| 7.6 | Working in secure areas |
| 7.7 | Clear desk and clear screen |
| 7.8 | Equipment siting and protection |
| 7.9 | Security of assets off-premises |
| 7.10 | Storage media |
| 7.11 | Supporting utilities |
| 7.12 | Cabling security |
| 7.13 | Equipment maintenance |
| 7.14 | Secure disposal or re-use of equipment |
Key Physical Controls — Details
7.1 — Physical Security Perimeters
- Divide physical areas into zones (Public vs. Restricted)
- Perimeter protection: Landscaping, Fences, Gates, Bollards, CCTV, Perimeter IDS
7.2 — Physical Entry & Biometrics
3-Step Access Control:
① Identification — Who are you? (badge, user ID, biometrics)
② Authentication — Prove it! (have / know / are)
③ Authorization — What can you do? (ACL-based)
| Auth Factor | Examples |
|---|---|
| Something you have | Badge, key, token |
| Something you know | PIN, password |
| Something you are | Fingerprint, iris scan, face |
Biometrics Errors:
| Error Type | What happens |
|---|---|
| False Negative (Type I) | Legitimate user is rejected |
| False Positive (Type II) | Unauthorized user is accepted |
7.6 — Working in Secure Areas
- Nobody may work alone in secure areas
7.11 — Supporting Utilities
- UPS (Uninterruptible Power Supply) — for short outages
- Generators / no-break systems — for longer outages
7.14 — Secure Disposal of Equipment
- Procedures + technical tools for secure disposal of media (paper, disks) with classified data
Physical Controls Guidance
- Zoning determines which areas need strict entry controls
- Access rights must interface tightly with HR (onboarding, offboarding, role changes)
- Check legislation before installing surveillance cameras (privacy laws)
- Physical controls managed by facilities management — must collaborate with ICT + security
- IT systems are vulnerable to electrical problems → backup power always required
- Physical barriers must not block emergency exits
3.3 People Controls — Section 6 (8 controls)
Full List
| Control | Name |
|---|---|
| 6.1 | Screening |
| 6.2 | Terms and conditions of employment |
| 6.3 | Information security awareness, education and training |
| 6.4 | Disciplinary process |
| 6.5 | Responsibilities after termination or change of employment |
| 6.6 | Confidentiality or non-disclosure agreements |
| 6.7 | Remote working |
| 6.8 | Information security event reporting |
Key People Controls — Details
6.1 — Screening
- Especially for high-risk positions (financial, high confidentiality)
- In case of fraud: investigating the employee's workstation may be the only legal option
6.3 — Information Security Awareness, Education & Training
Three aspects of InfoSec awareness:
| Aspect | Meaning |
|---|---|
| Knowledge | Understanding the rules |
| Attitude | Willingness to cooperate |
| Behavior | Actually obeying the rules |
Tools: Class-based training, e-learning, one-to-one talks, gaming, discussion Key: Behavioral change only occurs when people understand why controls exist
6.6 — NDA / Confidentiality Agreements
- Clarifies legal responsibilities for protecting confidential information
6.8 — Event Reporting
- Clarifies responsibilities for reporting security events
People Controls Guidance
- Four-eye principle: Admins should only use admin rights when another admin is present
- Duties should be separated to reduce risk
- Access rights reviewed periodically, especially when employees change roles
- Key issues: Background screening / Clear job descriptions / Segregation of duties / Training
3.4 Technological Controls — Section 8 (34 controls)
Full List
| Control | Name |
|---|---|
| 8.1 | User endpoint devices |
| 8.2 | Privileged access rights |
| 8.3 | Information access restriction |
| 8.4 | Access to source code |
| 8.5 | Secure authentication |
| 8.6 | Capacity management |
| 8.7 | Protection against malware |
| 8.8 | Management of technical vulnerabilities |
| 8.9 | Configuration management |
| 8.10 | Information deletion |
| 8.11 | Data masking |
| 8.12 | Data leakage prevention |
| 8.13 | Information back-up |
| 8.14 | Redundancy of information processing facilities |
| 8.15 | Logging |
| 8.16 | Monitoring activities |
| 8.17 | Clock synchronization |
| 8.18 | Use of privileged utility programs |
| 8.19 | Installation of software on operational systems |
| 8.20 | Networks security |
| 8.21 | Security of network services |
| 8.22 | Segregation of networks |
| 8.23 | Web filtering |
| 8.24 | Use of cryptography |
| 8.25 | Secure development life cycle |
| 8.26 | Application security requirements |
| 8.27 | Secure system architecture and engineering principles |
| 8.28 | Secure coding |
| 8.29 | Security testing in development and acceptance |
| 8.30 | Outsourced development |
| 8.31 | Separation of development, test and production environments |
| 8.32 | Change management |
| 8.33 | Test information |
| 8.34 | Protection of information systems during audit testing |
Key Technological Controls — Details
8.5 — Secure Authentication
Authentication method must match risk level:
| Access Type | Method |
|---|---|
| Internal web portal | Username + Password + MFA |
| VPN Access | Certificate + OTP Token |
| Developer API | OAuth 2.0 with scoped tokens |
| Service-to-Service | Mutual TLS with rotated certificates |
| Admin Dashboard | Hardware Token + Biometric |
8.7 — Protection Against Malware
- Malware spreads via USB sticks and infected websites
- Detection: signature-based OR behavior-based
- May generate false positives; may fail to detect all malware
- Logical bombs (hidden code that triggers later) — sometimes only detectable by human code review
8.11 — Data Masking
Purpose: Protect sensitive data (PII, financial, credentials) while preserving usability in non-production environments.
Masking Techniques:
| Technique | Description |
|---|---|
| Static Masking | Masked data stored permanently in non-prod environments |
| Dynamic Masking | Masked on-the-fly during access via proxy/middleware |
| Tokenization | Value replaced with token; original stored in secure vault |
| Substitution | Replaced with realistic fake values (e.g., fake names) |
| Shuffling | Randomly rearranges values within a column |
| Nulling / Redaction | Replaces with blanks, NULL, or **** |
Masking Example:
| Field | Original | Masked |
|---|---|---|
| Name | "John Smith" | "Alex Lee" (substituted) |
| Credit Card | "4111-1111-1111-1234" | "4111---1234" |
| "jane.doe@company.com" | "j***.***@company.com" | |
| National ID | "1234567890123" | "1234******123" |
Masking vs. Tokenization vs. Encryption:
| Property | Masking | Tokenization | Encryption |
|---|---|---|---|
| Reversible? | ❌ No (static) | ✅ Yes (via vault) | ✅ Yes (via key) |
| Format preserved? | ✅ Yes | ✅ Yes (configurable) | ❌ No |
| Primary use case | Dev/test environments | Payment processing (PCI) | Data in transit/at rest |
8.12 — Data Leakage Prevention (DLP)
What is data leakage? Unauthorized transfer of info outside org's boundaries.
| Type | Example |
|---|---|
| Unintentional | Misdirected email, copy-paste into chat |
| Malicious | Insider threat, exfiltration via backdoor |
| Unsecured endpoint | Uploading to personal cloud drive |
DLP Implementation — 5 Steps:
① Identify Sensitive Data — classify, tag/label (e.g., MIP sensitivity labels)
② Deploy DLP Technologies
├── Network DLP — monitors emails, web, FTP (data in motion)
├── Endpoint DLP — monitors USB, clipboard, print, screenshots
├── Cloud DLP — SaaS protection (M365, Google Workspace)
└── Content-Aware Inspection — regex/keyword (credit card numbers, national IDs)
③ Define DLP Policies — rules by content, context, channel
④ User Awareness & Training — educate on data handling
⑤ Monitor & Respond — log events, alert teams, integrate with SIEM/SOAR
DLP Policy examples:
- Block documents labelled "Confidential" from being emailed to personal addresses
- Block upload of spreadsheets with >10 SSNs to public cloud
- Alert when >100 files are downloaded by one employee in 1 hour
8.15 — Logging
Events that must be logged:
- Unauthorized access attempts
- Changes to configuration or data
- Privileged access attempts
- Creation / modification / deletion of user IDs
- System alarms
⚠️ Not all events = incident, but all events must be analyzed. All logs must be protected to preserve their own CIA (logs are evidence!).
8.19 — Software Installation on Operational Systems
- Only authorized admins may install software
- All software must be verified and tested for vulnerabilities first
- Use CMDB (Configuration Management DB) to track installed software and versions
- Use automated patch management to deploy vendor patches promptly
8.23 — Web Filtering
Purpose: Restrict access to malicious or non-business websites.
Implementation:
- DNS filtering — intercepts DNS queries, evaluates against threat intel + policy + content categories
- URL filtering + Secure Web Gateways
- Maintain logging and monitoring of all web access
DNS Filtering Flow:
User types URL → DNS query sent → DNS filter intercepts →
checks against blacklists / org policy / content categories →
Allow ✅ or Block ❌
Best practices: Principle of least privilege for web access; regularly update blacklists/whitelists; combine technical + administrative controls.
8.24 — Use of Cryptography
Cryptography achieves:
| Goal | Meaning |
|---|---|
| Confidentiality | Only authorized parties can read the data |
| Integrity | Data has not been tampered with |
| Non-repudiation | Sender cannot deny sending the message |
| Authentication | Verify identity of parties |
Cryptography policy must define:
- Principles for protecting information
- Link to data classification (which classification requires encryption)
- Encryption on specific vulnerable devices (phones, USB sticks)
- Standards: algorithm, key length, key management
Hardware Security Module (HSM)
A dedicated hardware device that protects encryption keys and accelerates cryptographic operations.
Software Cryptography Weaknesses vs. HSM Strengths:
| Issue | Software | HSM |
|---|---|---|
| Memory protection | Keys in memory can be read by other processes | Dedicated internal memory — inaccessible to outsiders |
| Integrity assurance | Code can be tampered with | Tamper-proof hardware |
| Reverse engineering | Code can be decompiled | No external access |
| OS dependency | Depends on OS security | Own micro-controller + crypto processor |
| Key storage | Subject to brute-force | Tamper-proof; key generation + usage + storage + destruction all within HSM |
| Performance | Unpredictable | Purpose-built cryptographic processor |
HSM FIPS Standards: ⭐ Exam Note
- FIPS 140-1 Level 2
- FIPS 140-2 Level 3 (higher assurance)
HSM Types:
| Type | Example |
|---|---|
| General Purpose | Luna SA |
| Network Attached | Luna SA |
| Payment HSM | Luna EFT2 |
| Authentication Token | iKey 5110 |
| PCI Card | Luna PCI-E / Protect Server External (PSE) |
8.20–8.22 — Network Security
Firewall Type Recap (from ISO perspective):
| Firewall Type | How It Works |
|---|---|
| Packet Filtering | Inspects header only; drops/rejects based on src/dst addr, protocol, port; no state tracking |
| Stateful | Records all connections; determines if packet is new/existing/unrelated; rules can include state |
| Application Layer | Understands app protocols (FTP, DNS, HTTP); detects protocol abuse or bypass attempts |
8.31 — Separation of Dev / Test / Production Environments
- Authorization required every time data is moved:
- Production → Test
- Test → Production
- Increases data integrity and ensures alignment with InfoSec policy
Service Oriented Architecture (SOA) & Security
- Architecture where apps use services available in the network
- Two roles: Service Provider (publishes services + contract) / Service Consumer (uses services)
- InfoSec team must be involved when designing SOA-based systems
Common Criteria (ISO/IEC 15408) — EAL Levels
- Framework for evaluating security products (firewalls, access control equipment)
- Three parties: Users (specify requirements) / Vendors (make claims) / Testing Labs (evaluate)
- Products receive an Evaluation Assurance Level (EAL):
| EAL Level | Assurance |
|---|---|
| EAL 1 | Basic (lowest) |
| EAL 4 | Methodically designed, tested, reviewed |
| EAL 7 | Formally verified design and tested (most stringent) |
5 Tips for Successful ISO 27001 Implementation
- Get senior management involved — policy enforcement + budget allocation
- Produce a gap analysis — may need professional consultants
- Gain cross-functional support from colleagues across departments
- Develop a project plan with key milestones
- Focus on continual improvement — PDCA never stops
⚡ Key Facts to Remember
| Fact | Detail |
|---|---|
| ISO 27001 uses | PDCA cycle — Plan (4–6) → Do (7–8) → Check (9) → Act (10) |
| 93 controls in | 4 themes: Org(37) + People(8) + Physical(14) + Tech(34) |
| SoA | Statement of Applicability — documents which controls are applied |
| Gap Analysis | Tells you what's missing vs. ISO 27001 |
| Risk Assessment | Tells you what controls to apply |
| Risk treatment options | Accept / Mitigate / Transfer / Avoid |
| RTO | Max time to restore a service after disaster |
| RPO | Max data loss acceptable (how old the backup can be) |
| BIA | Determines Maximum Acceptable Outage → feeds RTO |
| Data classification benefit ⭐ | Allows appropriate access control per class |
| Information classification levels | Public / Confidential / Highly Confidential |
| Threat intelligence levels | Strategic (exec) / Tactical (TTPs) / Operational (IoCs) |
| Four-eye principle | Admin actions require a second admin present |
| HSM FIPS 140-2 Level 3 ⭐ | High assurance hardware key protection standard |
| Static masking | Permanently replaces data in non-prod env — not reversible |
| Tokenization | Reversible via vault — used in payment processing (PCI) |
| Encryption | Reversible via key — used in transit/at rest — does NOT preserve format |
| DLP = | Prevent unauthorized data from leaving the org |
| Logging rule | All events must be analyzed; logs must be protected (CIA) |
| Biometric Type I error | False Negative — legitimate user rejected |
| Biometric Type II error | False Positive — unauthorized user accepted |
| EAL 7 | Most stringent Common Criteria assurance level |
| CMDB | Configuration Management DB — tracks installed software versions |
| Backup ≠ restore | Backup is only part of the solution — restore within RTO is the real challenge |