Fast memory phrases
| Topic | Memory phrase |
|---|---|
| Clauses 4-10 | Mandatory ISMS requirements; cannot be excluded |
| Annex A | Control reference set; risk-based selection |
| Statement of Applicability | Control decision and justification record |
| ISO 27002 | Implementation guidance and control attributes |
| Control attributes | Metadata for categorization and analysis |
| A.5.1 | Policies must be approved, communicated, acknowledged, controlled, and reviewed |
| A.5.2 | Responsibilities must be defined, allocated, communicated, accepted, and current |
| A.5.3 | Separate request, approval, execution, and review |
| A.5.4 | Security must be managed, not merely documented |
| A.5.5 | Know who to contact before authority contact is needed |
| A.5.6 | Use specialist communities for external security awareness |
| A.5.7 | Turn threat information into contextual intelligence |
| A.5.8 | Build security into projects from initiation to handover |
| A.5.9 | You cannot protect assets you do not know exist |
| A.5.10 | Tell people how assets may be used and handled |
| A.5.11 | Get assets and information back when access need ends |
| A.5.12 | Classify information by protection need |
| A.5.13 | Label information so classification drives handling |
| A.5.14 | Transfer information only through approved rules, procedures, or agreements |
| A.5.15 | Give access only when business need justifies it |
| A.5.16 | Manage identities from creation to removal |
| A.5.17 | Protect the secrets used to prove identity |
| A.5.18 | Access must be granted, reviewed, changed, and removed with evidence |
| A.5.19 | Supplier security risk must be managed, not assumed |
| A.5.20 | Supplier security requirements must be agreed before access or sharing |
| A.5.21 | ICT supplier risk includes the supplier’s supplier |
| A.5.22 | Supplier security must be monitored after go-live |
| A.5.23 | Cloud must be governed from acquisition through exit |
| A.5.24 | Incident response must be prepared before incidents happen |
| A.5.25 | Triage events and record the incident decision |
| A.5.26 | Respond to incidents using documented procedures |
| A.5.27 | Turn incidents into control improvement |
| A.5.28 | Preserve evidence with chain of custody |
| A.5.29 | Keep security alive during disruption |
| A.5.30 | Test ICT continuity against business recovery needs |
| A.5.31 | Know, own, update, and map legal/contractual obligations |
| A.5.32 | Protect IP rights and prove licence compliance |
| A.5.33 | Protect records through retention and keep them readable |
| A.5.34 | Know where PII is and meet privacy requirements |
| A.5.35 | Independent review gives objective assurance |
| A.5.36 | Regularly check policy and technical compliance |
| A.5.37 | Document procedures and control their versions |
| A.6.1 | Verify people before trust is granted |
| A.6.2 | Put security responsibilities into employment and contractual terms |
| A.6.3 | Train people before expecting secure behavior |
| A.6.4 | Make security violations formally actionable |
| A.6.5 | Remove old access and keep continuing duties alive |
| A.6.6 | Sign the right confidentiality agreement before disclosure |
| A.6.7 | Remote work needs more than VPN |
| A.6.8 | Report suspected events quickly through known channels |
| A.7.1 | Define physical zones before protecting them |
| A.7.2 | Control who enters secure areas |
| A.7.3 | Secure rooms based on what is inside |
| A.7.4 | Monitor premises and respond to physical intrusion |
| A.7.5 | Protect infrastructure from physical and environmental hazards |
| A.7.6 | Control how sensitive work is done inside secure areas |
| A.7.7 | Do not leave information exposed on desks, screens, printers, or media |
| A.7.8 | Site and protect equipment against damage, access, viewing, and interference risks |
| A.7.9 | Protect assets when they leave controlled premises |
| A.7.10 | Control storage media through its full lifecycle |
| A.7.11 | Keep critical processing facilities running when utilities fail |
| A.7.12 | Protect power and data cables from damage, interference, and interception |
| A.7.13 | Maintain equipment without exposing data or introducing tampering |
| A.7.14 | Sanitize or destroy equipment storage before disposal or reuse |
| A.8.1 | Protect information reachable through user endpoint devices |
| A.8.2 | Restrict and monitor privileged access rights |
| A.8.3 | Restrict information access by role, policy, classification, and business need |
| A.8.4 | Protect source code, development tools, and libraries |
| A.8.5 | Use risk-based secure authentication, not cosmetic MFA |
| A.8.6 | Monitor, forecast, and adjust capacity before availability fails |
| A.8.7 | Combine malware protection, updates, infection response, and user awareness |
| A.8.8 | Get vulnerability information, assess exposure, treat, and retest |
| A.8.9 | Define secure configurations, monitor drift, and manage exceptions |
| A.8.10 | Delete information when it is no longer required |
| A.8.11 | Mask or transform sensitive data when full visibility is not needed |
| A.8.12 | Prevent sensitive data from leaving through unapproved flows |
| A.8.13 | Maintain and test backups so information, software, and systems can be restored |
| A.8.14 | Implement redundancy sufficient to meet availability requirements |
| A.8.15 | Produce, protect, retain, and analyse useful logs |
| A.8.16 | Monitor anomalous behaviour and evaluate potential incidents |
| A.8.19 | Control software installation on operational systems |
| A.8.20 | Secure and manage network architecture, devices, zones, and traffic |
| A.8.21 | Identify, implement, and monitor security requirements for network services |
| A.8.22 | Segregate network groups to limit unauthorized access and lateral movement |
| A.8.23 | Filter external web access to reduce malicious content exposure |
| A.8.24 | Define crypto rules and manage keys through their lifecycle |
| A.8.25 | Establish and apply secure development rules |
| A.8.26 | Define and approve application security requirements |
| A.8.27 | Apply secure architecture and engineering principles |
| A.8.28 | Apply secure coding principles in actual code |
| A.8.29 | Test security during development and acceptance |
| A.8.30 | Govern supplier development instead of blindly accepting outsourced code |
| A.8.31 | Separate dev, test, and production with real access, network, data, and change controls |
| A.8.32 | Control changes with impact assessment, approval, testing, rollback, and records |
| A.8.33 | Protect test information; test environment does not lower data sensitivity |
| A.8.34 | Plan and agree audit testing before touching operational systems |
Control attributes
Think:
metadata, categorization, analysis, mapping, selection, review.
Imbalance
Think:
too many of one type of control and too few of another.
Over-protection
Think:
too many controls added after an incident without proportional risk justification.
Control selection
Think:
choose controls based on the desired risk treatment effect.
Framework mapping
Think:
using ISO attributes to correlate with NIST, CIS, SOC 2, PCI DSS, COBIT, etc.
Policy questions
When the exam asks about policies, look for words like:
- approved;
- communicated;
- acknowledged;
- reviewed;
- version controlled;
- management commitment;
- topic-specific;
- relevant personnel and interested parties.
Responsibility questions
When the exam asks about responsibilities, look for words like:
- defined;
- allocated;
- documented;
- communicated;
- accepted;
- current;
- contractors and third parties;
- accountability.
Segregation questions
When the exam asks about SoD, look for:
- conflicting duties;
- independent review;
- dual authorization;
- tamper-resistant logs;
- compensating controls;
- small organization limitations;
- primary accountability.
Management responsibility questions
When the exam asks about managers, look for:
- require personnel to apply policies;
- lead by example;
- reinforce security;
- verify compliance;
- remedial training;
- management messaging;
- security in day-to-day work.
External contact and intelligence questions
| Control | Look for | Avoid |
|---|---|---|
| A.5.5 Contact with Authorities | relevant authorities, liaison, triggers, approval, current contacts | generic phone list |
| A.5.6 Contact with Special Interest Groups | relevant forums, professional groups, internal sharing, confidentiality rules | membership badge with no use |
| A.5.7 Threat Intelligence | collection, analysis, context, validation, action | raw feeds or forwarded newsletters |
| A.5.8 Project Management | security requirements, risk traceability, change review, testing, transition | late security sign-off |
| A.5.9 Asset Inventory | information assets, associated assets, owners, classification, maintenance, disposal | hardware-only spreadsheet |
| A.5.10 Acceptable Use | documented rules, classification handling, acknowledgement, misuse response | policy nobody understands |
| A.5.11 Return of Assets | leavers, movers, contractors, information copies, secure erasure, inventory update | laptop-only return |
| A.5.12 Classification | clear levels, CIA needs, owner responsibility, handling rules, review | too many vague labels |
| A.5.13 Labelling | labels aligned to classification, physical/digital formats, persistence across form changes | labels that disappear or mean nothing |
| A.5.14 Information Transfer | approved channels, classification-based controls, third-party agreements, user awareness | email-only thinking |
| A.5.15 Access Control | physical/logical access, least privilege, owner approval, role profiles, reviews | seniority-based access |
| A.5.16 Identity Management | unique identities, joiner/mover/leaver, live identity review, shared-account exceptions | account creation only |
| A.5.17 Authentication Information | passwords/PINs/recovery answers/tokens, issue/reset control, user handling, default credential change | treating user IDs as secrets |
| A.5.18 Access Rights | request, approval, provisioning, review, modification, removal | access review as a checkbox |
| A.5.19 Supplier Relationships | supplier list, exposure, risk tier, agreements, subcontractors, review | procurement-only supplier list |
| A.5.20 Supplier Agreements | risk-based security terms, authorized agreement, responsibility split, deviations | generic contract with no security schedule |
| A.5.21 ICT Supply Chain | indirect suppliers, hosting, subcontractors, support parties, flow-down clauses | reviewing only the direct vendor |
| A.5.22 Supplier Monitoring | service reports, security reports, changes, incidents, nonconformities, reassessment | one-time onboarding |
| A.5.23 Cloud Services | acquisition, use, management, exit, data location, shared responsibility | assuming provider certification secures customer configuration |
| A.5.24 Incident Management Planning | process, roles, reporting, escalation, recovery, exercises, lessons learned | incident plan written but not communicated |
| A.5.25 Event Assessment | triage criteria, decision point, justification, categories, timelines | assuming every event is automatically an incident |
| A.5.26 Incident Response | documented response procedure, action log, roles, evidence decision, closure | ad hoc response with no record |
| A.5.27 Learning from Incidents | post-incident review, root cause, corrective action, training, control improvement | lessons learned with no tracked action |
| A.5.28 Evidence Collection | chain of custody, preservation, forensic copies, restricted storage | collecting screenshots without custody or integrity control |
| A.5.29 Security During Disruption | security continuity objectives, BIA security requirements, crisis roles, supplier security, exercises | continuity plans that restore operations while bypassing controls |
| A.5.30 ICT Readiness | RTO, RPO, recovery priorities, playbooks, restore testing, supplier ICT continuity | backup existence treated as proof of recoverability |
| A.5.31 Legal and Contractual Requirements | requirements register, owners, control mapping, legal advice, crypto rules, change tracking | generic compliance list with no owner or evidence |
| A.5.32 Intellectual Property Rights | software/content inventory, licence reconciliation, source-code rights, open-source review, AI output review | assuming software inventory alone proves licence compliance |
| A.5.33 Protection of Records | retention schedule, record inventory, access control, integrity, readability, disposal | keeping records but losing keys/software/readers needed to access them |
| A.5.34 Privacy and PII | PII inventory, purpose, justification, access, transfer, retention, breach notification | privacy policy with no PII inventory or requirement mapping |
| A.5.35 Independent Review | planned reviews, significant-change triggers, reviewer independence, management reporting, corrective action | security team reviewing its own work and calling it independent |
| A.5.36 Compliance Review | manager checks, technical checks, authorized competent testers, findings, root cause, retest | annual attestation with no technical evidence or follow-up |
| A.5.37 Operating Procedures | documented procedures, version control, authorized changes, accessibility, supplier procedures | procedures hidden in old wikis or personal knowledge |
Supplier control distinction
| Control | Core question |
|---|---|
| A.5.19 | Do we have a process to manage supplier security risk? |
| A.5.20 | Are the right security requirements agreed in the supplier contract or agreement? |
| A.5.21 | Have we considered ICT supply-chain dependencies beyond the direct supplier? |
| A.5.22 | Do we monitor, review, and manage supplier changes after service starts? |
| A.5.23 | Are cloud-specific acquisition, shared responsibility, data location, monitoring, and exit risks managed? |
| A.5.24 | Are incident management processes, roles, responsibilities, and reporting routes planned and communicated? |
Incident management control distinction
| Control | Core question |
|---|---|
| A.5.24 | Are incident management processes, roles, responsibilities, and reporting routes planned before incidents occur? |
| A.5.25 | Are reported events assessed and clearly classified as incidents or non-incidents? |
| A.5.26 | Are confirmed incidents responded to according to documented procedures? |
| A.5.27 | Are lessons from incidents used to improve controls and the ISMS? |
| A.5.28 | Is evidence identified, collected, acquired, and preserved so it remains reliable and usable? |
Continuity control distinction
| Control | Core question |
|---|---|
| A.5.29 | Will information security remain appropriate during crisis, disruption, and recovery? |
| A.5.30 | Can ICT services recover according to business continuity objectives and tested ICT continuity requirements? |
Legal and IP control distinction
| Control | Core question |
|---|---|
| A.5.31 | Does the organization know its legal, statutory, regulatory, and contractual information security obligations and how it meets them? |
| A.5.32 | Does the organization prevent unauthorized use, copying, licensing misuse, or unclear ownership of intellectual property? |
Records and privacy control distinction
| Control | Core question |
|---|---|
| A.5.33 | Are required records protected from loss, destruction, falsification, unauthorized access, and unauthorized release until retention ends? |
| A.5.34 | Are privacy and PII requirements identified and met for actual PII holdings, access, transfers, retention, and breach obligations? |
Assurance and procedure control distinction
| Control | Core question |
|---|---|
| A.5.35 | Is the information security approach and implementation independently reviewed at planned intervals and after significant changes? |
| A.5.36 | Is compliance with security policies, rules, standards, and technical baselines regularly reviewed and corrected? |
| A.5.37 | Are operating procedures documented, controlled, current, and available to personnel who need them? |
People control distinction
| Control | Core question |
|---|---|
| A.6.1 | Was the person appropriately screened before joining or receiving sensitive access? |
| A.6.2 | Did the person and organization accept clear information security responsibilities before work or access began? |
| A.6.3 | Did the person receive role-relevant awareness, education, training, and updates before needing to apply them? |
| A.6.4 | Is there a fair, communicated, evidence-based process for security policy violations? |
| A.6.5 | Are leaver/mover access, assets, notifications, and continuing duties controlled? |
| A.6.6 | Are confidentiality/NDA needs identified, signed before access, reviewed, and enforceable? |
| A.6.7 | Are remote work users, locations, activities, data, equipment, and controls authorized and verified? |
| A.6.8 | Do personnel know how to report observed or suspected events in time? |
| A.7.1 | Are physical perimeters defined and used for areas containing information and associated assets? |
| A.7.2 | Are entry points into secure areas controlled, logged, and reviewed where needed? |
| A.7.3 | Are offices, rooms, and facilities protected according to information value and risk? |
| A.7.4 | Are premises continuously monitored and are alarms escalated correctly? |
People controls exam cue
Common trap
A.6.1 is not maximum screening for everyone. It is lawful, ethical, proportional screening based on business need, information classification, and risk.
Common trap
A.6.2 is not just an NDA. Confidentiality matters, but the control is broader: employment and contractual terms should state information security responsibilities for personnel and the organization.
Common trap
A.6.3 is not just annual awareness attendance. Look for role relevance, timing, current content, records, understanding, and effectiveness review.
Common trap
A.6.5 covers role changes as well as leavers. Movers often retain old access and quietly break least privilege or segregation of duties.
Common trap
A.6.8 is event reporting, not the whole incident response lifecycle. It feeds A.5.25 assessment and A.5.26 response.
Physical control distinction
| Control | Core question |
|---|---|
| A.7.1 | Where are the physical boundaries protecting information and assets? |
| A.7.2 | Who can pass through access points into secure areas, and how is this controlled? |
| A.7.3 | Are rooms and facilities designed to protect what they contain? |
| A.7.4 | Is unauthorized physical access detected and handled? |
- Exam
- Iso27001
- Iso27002
Note Metadata
Aliases: Quick Exam Cues
Source: 03 Exam Prep/Exam Cues.md