ISO27001 ISMS KB - Start Here
This knowledge base contains expanded study notes for ISO/IEC 27001 and ISO/IEC 27002.
802 published notes organized across 26 sections and 54 subsections.
Section
1 notes across 1 subsections
This knowledge base contains expanded study notes for ISO/IEC 27001 and ISO/IEC 27002.
Section
15 notes across 2 subsections
Annex A is a reference set of information security controls. The organization uses it to make sure it has not overlooked relevant controls when treating risks.
1. Clauses 4-10 — mandatory ISMS management-system requirements. 2. Annex A controls — a reference set of information security controls used for risk treatment and the Statement...
Access control is the set of rules and mechanisms used to decide who can access information and systems, what they can do, and how that access is approved, changed, reviewed, an...
Control attributes are useful only if they help link a control to the risk treatment outcome you need.
This topic explains who the guide is for, how ISO/IEC 27001 and ISO/IEC 27002 relate to each other, and what it means to claim compliance with ISO/IEC 27001.
An Information Security Management System is the structured set of policies, processes, roles, risks, controls, evidence, audits, management reviews, and improvement activities...
An information security policy is management's approved statement of what the organization expects for protecting information. It sets direction, assigns high-level expectations...
Internal audit checks whether the ISMS conforms to ISO/IEC 27001 requirements, the organization's own requirements, and whether it is effectively implemented and maintained.
A control is the actual safeguard. An attribute is a label describing the safeguard.
Management responsibilities means managers must make sure people follow the organization's information security policies, procedures, and role expectations. The security team ca...
Management review is the formal process where top management reviews ISMS performance, suitability, adequacy, and effectiveness.
Risk assessment identifies, analyzes, and evaluates information security risks so the organization can decide how to treat them.
Roles and responsibilities define who is accountable for information security activities, who performs them, who approves them, and who must be consulted or informed.
Segregation of duties means sensitive work should be split so one person cannot request, approve, perform, and review the same activity without independent control.
The Statement of Applicability, usually called the SoA, is the ISO/IEC 27001 control decision record.
Section
7 notes across 1 subsections
Placeholder clause card for Dataview tracking. Expand this when clause-specific study material is added.
Placeholder clause card for Dataview tracking. Expand this when clause-specific study material is added.
Placeholder clause card for Dataview tracking. Expand this when clause-specific study material is added.
Placeholder clause card for Dataview tracking. Expand this when clause-specific study material is added.
Placeholder clause card for Dataview tracking. Expand this when clause-specific study material is added.
Placeholder clause card for Dataview tracking. Expand this when clause-specific study material is added.
Placeholder clause card for Dataview tracking. Expand this when clause-specific study material is added.
Section
39 notes across 2 subsections
Organizational controls establish governance, accountability, policy, process, and oversight for the ISMS.
Research note.
Information security policy and topic-specific policies should be defined, approved by management, published, communicated to and acknowledged by relevant personnel and relevant...
People must know how they are allowed to use organizational information and assets, and how they must handle information based on sensitivity and classification.
When someone leaves, changes role, ends a contract, or no longer needs an asset, the organization must get its assets back and ensure organizational information is returned or s...
Information must be grouped by protection need so people know how carefully to handle it.
If information is classified, people need a practical way to see or infer the classification so they can handle it correctly.
The organization must define how information can be transferred safely, both internally and externally.
The organization must define and enforce rules for who can access information, systems, services, networks, applications, repositories, and physical locations.
Every user identity should be created, changed, reviewed, disabled, and removed through a controlled process.
The organization must control how secret authentication information is issued, changed, protected, reset, and handled.
Access rights must be granted, changed, reviewed, and removed through a controlled process.
The organization must manage information security risks created by suppliers, supplier products, and supplier services.
Information security roles and responsibilities must be defined and allocated according to organizational needs.
The organization must put the right security requirements into supplier contracts or agreements before the supplier receives access to information, systems, facilities, or servi...
The organization must manage security risks that come through ICT suppliers and the suppliers behind those suppliers.
Supplier security does not end when the contract is signed. The organization must keep checking whether the supplier is delivering the agreed service securely, whether controls...
Cloud services must be governed from selection to exit. The organization needs defined processes for buying, configuring, using, monitoring, changing, and leaving cloud services...
The organization must prepare before incidents happen. It needs defined and communicated incident management processes, roles, responsibilities, escalation paths, and recovery c...
The organization must review reported security events and make a clear, recorded decision: is this just an event, or is it an information security incident that needs formal res...
Once an event is categorized as an incident, the organization must respond using documented procedures rather than improvising.
The organization must turn incident experience into better controls, procedures, awareness, risk treatment, and response capability.
The organization must know how to identify, collect, acquire, preserve, store, and protect evidence related to security events so it remains complete, reliable, and usable.
The organization must decide in advance how information security will be maintained during serious disruption, crisis, disaster recovery, or business continuity events.
No single person should be able to perform a sensitive activity from beginning to end without independent oversight, approval, review, or control.
The organization must plan, build, maintain, and test ICT continuity capability so priority systems and services can recover in line with business continuity objectives.
The organization must know which legal, statutory, regulatory, and contractual information security requirements apply, document them, keep them current, and define how it will...
The organization must have procedures that prevent unauthorized use, copying, distribution, modification, or licensing misuse of software, documents, designs, source code, trade...
The organization must protect required records for as long as they need to be retained, so they are not lost, destroyed, falsified, accessed without authorization, or released w...
The organization must identify privacy and PII protection requirements that apply to the personal information it collects, stores, processes, transmits, shares, or retains, then...
The organization must have its information security management approach and actual implementation independently reviewed at planned intervals and when significant changes happen.
The organization must regularly check whether people, processes, and systems comply with its information security policies, rules, standards, and technical implementation requir...
The organization must document operating procedures for information processing facilities and make the current approved procedures available to the people who need to use them.
Management must require all personnel to apply information security in accordance with the organization's information security policy, topic-specific policies, and procedures.
The organization must know which external authorities matter for information security and must maintain usable contact paths before an incident, investigation, regulatory reques...
The organization should stay connected to credible external security knowledge sources. Security teams should not rely only on internal experience, vendor marketing, or outdated...
The organization must collect threat information, analyze it in context, and turn it into usable intelligence for decisions.
Projects must handle information security from the start, not as a late review before go-live.
The organization must know what information and related assets it has, where they are, who owns them, how important they are, and how they are protected.
Section
9 notes across 2 subsections
A.5 is mostly governance and organizational control design. A.6 is about personnel trust and behavior. In an audit, A.6 evidence usually comes from HR, recruitment, line managem...
The organization should check that people are who they claim to be, have the relevant background for the role, and do not present unmanaged personnel risk before they join or re...
People should not have to guess what they are responsible for. Employment contracts, contractor agreements, confidentiality agreements, onboarding acknowledgements, or security...
People need to know how to behave securely in their actual role. Everyone needs baseline awareness, but people with specific responsibilities need deeper training that matches t...
The organization needs a documented and communicated process for handling information security policy violations. People should know that violations can lead to action, and mana...
When someone leaves the organization or changes role, their old access, assets, and responsibilities must be handled deliberately. Some rights should stop immediately. Some duti...
The organization should know when confidentiality or non-disclosure agreements are needed, use terms that match its information-protection needs, keep those agreements legally u...
When people work away from organization premises, the organization still has to protect information. That includes homes, hotels, coffee shops, customer sites, temporary offices...
People need to know what might be a security event, how to report it, who to report it to, and what not to do. Reporting should be fast, simple, and no-blame enough that people...
Section
3 notes across 1 subsections
Research note.
- approved; - communicated; - acknowledged; - reviewed; - version controlled; - management commitment; - topic-specific; - relevant personnel and interested parties.
Annex A is not a mandatory checklist for every organization. It is a reference set of controls used to help the organization check whether it has overlooked relevant risks or co...
Section
15 notes across 2 subsections
A.5 defines organizational governance and A.6 defines people behavior and personnel lifecycle controls. A.7 tests whether the physical environment supports those decisions. The...
The organization should know which physical areas need protection and where the boundaries are. A perimeter can be a building boundary, floor, room, cage, cabinet, loading area,...
The organization should control storage media from the moment it is obtained until it is erased, destroyed, disposed of, or transferred. Media includes digital and physical carr...
Information processing facilities need supporting utilities to operate. Electricity, cooling, ventilation, telecommunications, water, fire protection, emergency lighting, and bu...
Cables are part of the information processing environment. If they are badly routed, unprotected, mixed incorrectly, poorly labelled, or accessible to unauthorized people, they...
Equipment that runs reliably today can still fail tomorrow. The organization should define maintenance needs, follow supplier recommendations, use authorized maintainers, keep m...
Before equipment is reused, sold, returned, repaired, donated, recycled, or discarded, the organization should verify that sensitive information and licensed software are no lon...
If an area is secure, entry should be controlled. The organization should know who is allowed in, how entry is verified, how visitors are handled, how delivery/loading areas are...
The organization should design and implement physical protections for offices, rooms, and facilities based on what those areas contain and how critical or sensitive the work is.
The organization should monitor premises for unauthorized physical access, similar to how networks are monitored for intrusion. Monitoring may be manual, automated, or a mix of...
The organization should protect sites, buildings, rooms, and infrastructure from hazards such as fire, flood, explosion, chemical leaks, civil unrest, utility failure, and threa...
The organization should define how people work inside secure areas when the work itself is sensitive or critical. Physical entry controls are not enough. The rules must also cov...
People should not leave sensitive papers, removable media, printed documents, fax messages, or unlocked screens exposed where unauthorized people can see, photograph, remove, al...
The organization should place and protect equipment in a way that reduces physical damage, environmental damage, unauthorized access, unauthorized use, and information exposure.
The organization should protect equipment, documents, data, software, and storage media when they leave the organization's controlled environment.
Section
92 notes across 5 subsections
The auditor wants to confirm that information security policies are defined, approved, published, communicated, acknowledged, controlled, and reviewed.
The auditor wants to confirm that acceptable use rules and information handling procedures are defined, communicated, acknowledged, implemented, and enforced for relevant users...
The auditor wants to confirm that employees, contractors, third-party users, and other relevant parties return organizational assets when employment, contract, agreement, or rol...
The auditor wants to confirm that the organization has a clear, usable classification scheme and that information is classified according to confidentiality, integrity, availabi...
The auditor wants to confirm that labelling procedures exist, align with the classification scheme, and are implemented across relevant physical and digital forms of information.
The auditor wants to confirm that the organization has documented and implemented rules, procedures, or agreements for transferring information internally and externally across...
The auditor wants to confirm that physical and logical access rules are defined, implemented, approved, reviewed, and based on business and information security requirements.
The auditor wants to confirm that identities are uniquely registered where possible and managed through the full lifecycle: creation, authorization, change, review, disabling, d...
The auditor wants to confirm that secret authentication information is issued, managed, changed, reset, stored, and handled through a controlled process, and that users understa...
The auditor wants to confirm that access rights are formally provisioned, reviewed, modified, and removed according to access control rules.
The auditor wants to confirm that supplier information security risks are identified, assessed, controlled, contractually addressed, and reviewed.
The auditor wants to confirm that information security roles and responsibilities are defined, allocated, documented, communicated, understood, accepted, current, and applied to...
The auditor wants to confirm that supplier security requirements are established, agreed, authorized, and appropriate to the supplier relationship before access or information s...
The auditor wants to confirm that ICT supply-chain risks are identified and managed, including inherited risks from subcontractors, cloud providers, support parties, hosting pro...
The auditor wants to confirm that supplier security practices and service delivery are monitored, reviewed, evaluated, and changed through a controlled process.
The auditor wants to confirm that cloud service acquisition, use, management, and exit are governed according to the organization's information security requirements.
The auditor wants to confirm that incident management processes, roles, responsibilities, reporting routes, and preparation activities are defined, established, communicated, an...
The auditor wants to confirm that reported security events are assessed using defined criteria and that the incident/non-incident decision is recorded with justification and tim...
The auditor wants to confirm that confirmed information security incidents are responded to according to documented procedures and that response decisions, actions, responsibili...
The auditor wants to confirm that knowledge from incidents is captured and used to improve controls, procedures, awareness, risk treatment, and the ISMS.
The auditor wants to confirm that procedures exist and operate for identifying, collecting, acquiring, preserving, storing, and protecting evidence related to information securi...
The auditor wants to confirm that information security is maintained at an appropriate level during disruption and that continuity plans include security objectives, roles, requ...
The auditor wants to confirm that conflicting duties and responsibilities have been identified and segregated, or that compensating controls exist where segregation is not pract...
The auditor wants to confirm that ICT readiness is planned, implemented, maintained, and tested based on business continuity objectives and ICT continuity requirements.
The auditor wants to confirm that applicable legal, statutory, regulatory, and contractual information security requirements are identified, documented, owned, kept current, and...
The auditor wants to confirm that procedures protect intellectual property rights and that software, content, source code, libraries, and AI-generated material are used within a...
The auditor wants to confirm that required records are identified, retained, protected from loss/alteration/unauthorized access/release, reviewed, accessible through retention,...
The auditor wants to confirm that privacy and PII requirements are identified, mapped, implemented, reviewed, and evidenced for all relevant PII holdings, roles, transfers, and...
The auditor wants to confirm that the information security approach and implementation are independently reviewed at planned intervals and after significant changes, with findin...
The auditor wants to confirm that compliance with information security policies, rules, and standards is regularly reviewed through management and technical checks, with finding...
The auditor wants to confirm that operating procedures for information processing facilities are documented, controlled, current, available to personnel who need them, and used...
The auditor wants to confirm that managers actively require personnel to apply information security according to policies and procedures.
The auditor wants to confirm that the organization has identified relevant authorities, assigned authorized liaison roles, defined contact triggers, maintained accurate contact...
The auditor wants to confirm that the organization maintains proportionate contact with relevant specialist security groups, forums, or professional associations and that useful...
The auditor wants to confirm that threat information is collected, analyzed, validated, contextualized, and used to support risk assessment, risk treatment, control improvement,...
The auditor wants to confirm that information security is integrated into the project management method and applied in real projects from initiation through transition to operat...
The auditor wants to confirm that information and associated assets are identified, owned, classified, maintained, protected, and updated through change, project, procurement, a...
The auditor wants evidence that background verification checks are defined, applied, documented, and protected as personal data.
The auditor wants evidence that security responsibilities are defined, accepted, role-appropriate, current, and applicable to employees, contractors, and third-party users in sc...
The auditor wants evidence that training is role-relevant, current, recorded, repeated where needed, and improved based on effectiveness feedback.
The auditor wants evidence that the organization can respond fairly and consistently when personnel or relevant interested parties violate information security policy.
The auditor wants proof that old access and assets are removed, relevant parties are notified, and continuing duties are communicated after termination or role change.
The auditor wants evidence that agreements reflect actual confidentiality requirements and are legally usable where needed.
The auditor wants evidence that information remains protected when accessed, processed, or stored outside organization premises.
The auditor wants proof that reporting channels are known, usable, timely, and connected to event assessment and incident management.
The auditor wants evidence that physical zones protect assets and information, not just a floorplan showing rooms.
- Media handling follows classification. - Media is inventoried and labelled where appropriate. - Dispatches are authorized and recorded. - Sensitive media is protected during t...
- Critical facilities have documented utility dependencies. - UPS/generator tests include load, runtime, cooling, and maintenance evidence. - Alarms detect utility failures and...
- Cable routes are documented and protected. - Power/data segregation is implemented where needed. - Patch panels, cabinets, and connections are locked or access-controlled. - L...
- Maintenance is scheduled and recorded. - Faults and repairs are tracked. - Maintainers are authorized and qualified. - External maintainers are escorted where required. - Conf...
- Records identify asset, storage media, classification, method, verifier, and date. - Sanitization method matches media type and sensitivity. - Contractor records are asset-spe...
The auditor wants evidence that only authorized people can enter secure areas and that visitor, badge, delivery, and loading controls operate in practice.
- Controls are based on value, liability, importance, and classification. - Sensitive room purpose is not unnecessarily exposed. - Internal directories and access clues are prot...
- Monitoring scope is documented and risk-based. - Alerts have owners, response times, and escalation paths. - Monitoring tests are performed and recorded. - Monitoring staff kn...
- Hazard assessment includes site, room, utility, and neighbor risks. - Specialist advice exists for material hazards. - Controls are implemented and maintained. - Continuity ar...
- Secure-area work is identified and risk-assessed. - Need-to-know, device, media, supervision, and dual-control rules are documented. - Employees, contractors, and third partie...
- Rules cover papers, removable media, screens, printers, faxes, storage, and confidential waste. - Auto-lock settings are enforced. - Sensitive print/fax workflows are controll...
- Equipment inventory includes location, owner, and protection requirement. - Siting assessment covers physical, environmental, viewing, access, and interference risks. - Networ...
- Asset removal is authorized and logged. - Off-site assets are recorded with custodian, location, and review date. - Mobile devices are encrypted and managed. - Long-term loans...
1. Design — is the control defined appropriately? 2. Implementation — has it been put in place? 3. Operation — is it operating as intended? 4. Evidence — can the organization pr...
- Device inventory includes managed and BYOD endpoints. - Compliance reports show patching, encryption, screen lock, and malware/EDR status. - Remote access requires strong auth...
- Deletion records match retention rules. - Deletion method matches sensitivity and storage type. - Items awaiting destruction are secured. - Cloud and backup data are included....
- Masking methods are defined and matched to use cases. - Full-data access is role-based and approved. - Token lookup tables/keys are segregated. - Re-combination is logged and...
- DLP scope maps to sensitive/classified information. - Approved data flows and channels are defined. - DLP rules are tuned to the organization’s risk and data types. - Alerts a...
- Backup scope maps to critical information, systems, and software. - Frequency aligns with risk and continuity requirements. - Restore tests are documented and successful. - Ba...
- Redundancy is linked to RTO/RPO and service criticality. - Critical dependencies are included. - Failover tests meet target recovery times. - Data replication and alternate-si...
- Logs include event, user/account, date/time, source, and action. - Privileged activity is logged and independently reviewed. - Logs are protected from source-system administra...
- Detection use cases trace to risk scenarios, assets, and critical services. - Monitoring source coverage includes relevant identity, endpoint, server, network, cloud, applicat...
- Installation records link to approved changes. - Security, compatibility, and regression tests are retained. - Deployment was performed by authorized personnel. - Production i...
- Privileges are approved based on need-to-use. - Separate named admin IDs exist where feasible. - Privileged activity is logged and reviewed. - Logs are protected and retained....
- Diagrams match actual network configuration. - Sensitive traffic paths and public network exposure are identified. - Network zones are enforced and tested. - Network device ad...
- Network services have owners and risk assessments. - Required security mechanisms are documented. - Agreements include security features and service levels. - Provider reports...
- Zones are risk-based and documented. - Systems and services are assigned to zones. - Inter-zone rules are specific and reviewed. - Wireless and cloud networks are included. -...
- Categories are mapped to policy and risk. - Filtering covers remote users and relevant devices. - Exceptions have approval, owner, and review date. - Users cannot casually dis...
- Cryptographic decisions trace to risk and classification. - Algorithms, key lengths, and protocols are approved and current. - Keys have owners, purpose, lifecycle status, and...
- Secure development rules are mandatory and integrated into workflow. - Developers and reviewers have relevant training. - Reviews are performed by competent reviewers, not onl...
- Requirements are specific and testable. - Requirements trace to risk, classification, and legal obligations. - Security and business owners approve requirements. - Testing pro...
- Principles are specific and usable. - Architecture reviews reference principles. - Threat models identify and treat design risks. - Deviations are risk-assessed and approved....
- Standards are language, framework, and risk-specific. - Developers can retrieve and explain applicable standards. - Automated checks run and findings are reviewed. - Secure co...
- Test depth and frequency trace to risk. - Testing occurs during development and before acceptance. - Acceptance criteria are documented. - Defective input, regression, access...
- Access rules are approved by the information or application owner. - Role permissions are mapped to create/read/modify/delete/export/admin rights. - Application and database p...
- Contracts include secure development, testing, IP, audit, and training requirements. - Supplier deliverables have test and review evidence. - Findings are tracked to closure o...
- Access differs between development, test, and production. - Production deployments require approval and release records. - Network and administrative paths are restricted and...
- Security impact is assessed before approval. - Testing and rollback are proportionate to risk. - Implementation logs match approved changes. - Release records identify include...
- Synthetic or masked data is the default. - Each live-data use is authorized. - Test environments protect sensitive data appropriately. - Logs, caches, screenshots, and debug f...
- Operational testing is planned before execution. - Scope, tools, timing, contacts, and stop criteria are documented. - Appropriate management authorizes the activity. - Tool u...
- Source code is centrally stored in controlled repositories. - Read/write/merge/build/release permissions are separated. - Changes require review, approval, and test evidence....
- MFA is implemented for remote, privileged, and high-risk access where required. - MFA uses different factor types. - Failed logon handling includes lockout, delay, throttling,...
- Critical systems have defined capacity plans. - Monitoring covers current and expected bottlenecks. - Trend analysis is reviewed and acted on. - Thresholds have owners and act...
- Malware protection coverage is inventoried. - Updates are monitored and exceptions are investigated. - Real-time scanning is enabled where feasible. - Sensitive/shared systems...
- Scanning covers all relevant systems. - Vulnerabilities have owners, severity, risk rating, and target dates. - Critical issues are prioritized by exploitability and exposure....
- Baselines exist for major technology types. - Systems are mapped to applicable baselines. - Compliance is checked regularly or continuously. - Exceptions include risk rational...
Section
59 notes across 1 subsections
Audit question set for ISO27001-A.7.12. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.7.13. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.7.14. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.7.10. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.7.11. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.7.9. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.7.8. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.6.1. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.6.2. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.6.3. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.6.4. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.6.5. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.6.6. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.6.7. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.6.8. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.7.1. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.7.2. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.7.3. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.7.4. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.7.5. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.7.6. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.7.7. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.33. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.34. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.35. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.36. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.37. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.23. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.24. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.25. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.26. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.27. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.28. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.29. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.30. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.31. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.32. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.1. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.10. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.11. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.12. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.13. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.14. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.15. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.16. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.17. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.18. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.19. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.2. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.20. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.21. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.22. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.3. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.4. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.5. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.6. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.7. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.8. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Audit question set for ISO27001-A.5.9. Use it to validate implementation, operating evidence, exceptions, review cadence, ownership, and corrective action.
Section
33 notes across 2 subsections
A.5 sets governance rules, A.6 manages people responsibilities, and A.7 protects the physical environment. A.8 tests whether technical systems enforce and evidence those decisions.
The organization should protect laptops, desktops, mobile phones, tablets, personal devices, and other endpoint devices that users rely on to access organizational information.
The organization should not keep information forever just because storage is cheap. When information is no longer needed for business, legal, regulatory, contractual, or evidenc...
The organization should hide, replace, tokenize, pseudonymize, or anonymize sensitive data where full visibility is not needed. The goal is to let people or systems use data for...
The organization should prevent sensitive information from leaving approved locations, systems, networks, or channels without authorization. This requires understanding which in...
The organization should make backup copies of important information, software, and systems, protect those backups, and regularly test whether they can actually be restored.
The organization should design critical processing facilities so that a single failure does not create unacceptable downtime. Redundancy may involve duplicate equipment, cluster...
The organization should collect useful logs, protect them from tampering, keep them long enough, and review or analyse them so security-relevant events can be detected and inves...
The organization should actively watch important technology environments for signs that something abnormal or suspicious is happening. Monitoring should help detect possible att...
Operational systems should not accept software changes just because someone has technical ability to install them. New software, updates, libraries, patches, scripts, packages,...
Privileged access allows users to administer systems, override controls, change configurations, access sensitive data, or recover systems during failure. Because privileged acce...
Networks are not just cables and routers. They are trust paths between users, systems, applications, cloud services, suppliers, and management interfaces. If the network is poor...
When the organization uses network services, especially third-party network services, it should know exactly what security features and service levels are required, what the pro...
Large flat networks are hard to defend. Network segregation divides users, systems, and services into smaller physical or logical zones so traffic between them can be controlled.
Users can be compromised by visiting malicious websites, downloading fake tools, following phishing links, or connecting to command-and-control infrastructure. Web filtering red...
The organization should define when cryptography is required, what approved cryptographic methods may be used, who manages keys, how keys are protected, and how cryptographic co...
Development work should follow secure rules from the beginning. This applies to software, services, networks, infrastructure, environments, and systems that are built or changed...
Application security requirements should be defined before the application is built, bought, integrated, or changed. The organization should decide what security the application...
The organization should define architectural and engineering principles that guide how systems are designed securely. These principles should be documented, maintained, and used...
Developers should follow secure coding standards that fit the languages, frameworks, tools, and risk level of the software being built. The standard should explain both general...
Security testing should be planned, performed, recorded, and used as part of development and acceptance. It should not be left until the final days before go-live.
The organization should make sure users can only access the information, functions, applications, databases, reports, exports, and assets they need for their role.
If a supplier builds software or systems for the organization, the organization still owns the security outcome. Outsourcing the work does not outsource accountability.
Developers need places to build and test. Production needs stability, integrity, and controlled access. These environments should not be casually mixed.
Changes to systems, infrastructure, networks, applications, code, integrations, operational processes, and information processing facilities should be planned, reviewed, approve...
Test data should be chosen deliberately. Synthetic or fictitious data is usually safer. If production data is used for testing, it must be justified, authorized, protected, logg...
Audits, penetration tests, vulnerability scans, configuration reviews, data extraction, and assurance tools can disrupt systems or expose information if they are not planned. Te...
Source code, build tools, compilers, package repositories, CI/CD pipelines, and software libraries can directly change how systems behave. If an attacker or unauthorized insider...
Authentication is the point where a system tests whether the person, service, or device claiming an identity should be accepted. Secure authentication means the logon process do...
The organization should know whether its systems, networks, storage, cloud services, databases, staff, and other resources can support current and future demand. Capacity manage...
The organization should reduce the chance that malicious software infects systems, spreads through files or connected services, damages information, or gives attackers unauthori...
The organization should actively find out what vulnerabilities affect its systems, assess how exposed it is, and respond in a risk-based timeframe. Response can include patching...
The organization should define what secure and acceptable configuration looks like, apply it, monitor whether systems stay aligned to it, and review exceptions. If approved conf...
Section
6 notes across 2 subsections
This guide is the implementation view of the vault. It explains how to build and operate an ISMS using the existing ISO/IEC 27001 notes, Annex A controls, templates, evidence pa...
This note converts the covered A.5 control library into an implementer view. Use the individual control notes for detail and this guide for build sequencing.
1. Identify people categories in ISMS scope: employees, contractors, temporary staff, consultants, and third-party users. 2. Map role risk using access level, information classi...
1. Identify areas containing information and associated assets. 2. Classify zones by business process, asset sensitivity, customer/regulatory need, and risk. 3. Define perimeter...
1. Identify systems, endpoints, users, privileged access paths, information repositories, source repositories, authentication paths, critical capacity resources, malware protect...
- Start with the business and risk context, not Annex A. - Treat Annex A as a control library, not a mandatory checklist. - Keep evidence close to the process that creates it. -...
Section
15 notes across 1 subsections
Because incident ownership, escalation criteria, and communication paths are not prepared or rehearsed, a serious security incident may be handled slowly or inconsistently.
Because reported security events are not assessed with clear criteria, a material incident may be dismissed, delayed, or escalated without the evidence needed for response.
Because confirmed incidents are handled without a documented response record and authority model, containment may be delayed or inconsistent across teams.
Because incident knowledge is not converted into corrective actions, the same failure mode may recur and leave the organization exposed to preventable incidents.
Because incident evidence is collected or stored without integrity controls, investigation, legal, regulatory, disciplinary, or audit conclusions may not be defensible.
Because access rules are not clearly defined, approved, and reviewed, users may have more access than their role requires across sensitive systems, data, repositories, or locations.
Because identities are not managed through a controlled lifecycle, inactive, duplicate, stale, or shared identities may remain usable after users change roles or leave.
Because secret authentication information is not issued, reset, stored, and protected through controlled procedures, credentials may be exposed, reused, guessed, or misused.
Because access rights are not reviewed, modified, and removed after role, employment, supplier, or system changes, users may retain access that is no longer justified.
Because suppliers, products, and services are not inventoried, owned, risk-tiered, and periodically reviewed, the organization may accept security exposure without knowing who is accountable or what controls apply.
Because supplier security requirements are not formally agreed before information sharing or access begins, the organization may rely on informal expectations that cannot be enforced during incidents, disputes, audits, or termination.
Because ICT supplier dependencies, subcontractors, hosting platforms, software components, and support parties are not identified or reviewed, a compromise or control failure outside the direct supplier may affect the organization.
Because supplier service reports, security practices, incidents, and material changes are not actively reviewed, supplier risk may increase after onboarding without triggering control updates or management decisions.
Because cloud services are not governed from acquisition through use, monitoring, change, and exit, the organization may misunderstand shared responsibility, misconfigure security controls, lose data location visibility, or fail to exit safely.
Because of ransomware actors exploiting an unpatched VPN and weak monitoring affecting the customer database, customer data compromise and operational disruption may occur.
Section
6 notes across 2 subsections
This guide is the audit view of the vault. It turns the ISO/IEC 27001 and Annex A notes into audit planning, evidence testing, interview questions, findings, and corrective acti...
This note gives the audit view for the currently documented A.5 organizational controls. Use the evidence packs for detailed requests and this guide for audit logic.
1. Select samples across employees, contractors, temporary staff, and third-party users. 2. Compare onboarding dates, agreement dates, screening completion dates, and access pro...
1. Review zone registers, floor/security diagrams, and risk assessment. 2. Walk the physical site and test practical bypass paths. 3. Observe badge use, visitor handling, recept...
1. Review policies and standards before sampling technical evidence. 2. Sample endpoint inventory against MDM/EDR/compliance reports. 3. Check remote access, timeout, encryption...
- What risk does this control treat? - Who owns the control? - How do you know it operated during the audit period? - What happens when the control fails? - What evidence would...
Section
91 notes across 4 subsections
The organization must protect required records for as long as they need to be retained, so they are not lost, destroyed, falsified, accessed without authorization, or released without authorization.
The organization must identify privacy and PII protection requirements that apply to the personal information it collects, stores, processes, transmits, shares, or retains, then implement controls to meet those requirements.
The organization must have its information security management approach and actual implementation independently reviewed at planned intervals and when significant changes happen.
The organization must regularly check whether people, processes, and systems comply with its information security policies, rules, standards, and technical implementation requirements.
The organization must document operating procedures for information processing facilities and make the current approved procedures available to the people who need to use them.
Cloud services must be governed from selection to exit. The organization needs defined processes for buying, configuring, using, monitoring, changing, and leaving cloud services in line with its security requirements.
The organization must prepare before incidents happen. It needs defined and communicated incident management processes, roles, responsibilities, escalation paths, and recovery coordination.
The organization must review reported security events and make a clear, recorded decision: is this just an event, or is it an information security incident that needs formal response?
Once an event is categorized as an incident, the organization must respond using documented procedures rather than improvising.
The organization must turn incident experience into better controls, procedures, awareness, risk treatment, and response capability.
The organization must know how to identify, collect, acquire, preserve, store, and protect evidence related to security events so it remains complete, reliable, and usable.
The organization must decide in advance how information security will be maintained during serious disruption, crisis, disaster recovery, or business continuity events.
The organization must plan, build, maintain, and test ICT continuity capability so priority systems and services can recover in line with business continuity objectives.
The organization must know which legal, statutory, regulatory, and contractual information security requirements apply, document them, keep them current, and define how it will meet them.
The organization must have procedures that prevent unauthorized use, copying, distribution, modification, or licensing misuse of software, documents, designs, source code, trademarks, patents, subscription content, and AI-generated or AI-assisted material.
The organization needs a formal information security policy structure, not random documents sitting in a shared folder.
People must know how they are allowed to use organizational information and assets, and how they must handle information based on sensitivity and classification.
When someone leaves, changes role, ends a contract, or no longer needs an asset, the organization must get its assets back and ensure organizational information is returned or securely removed.
Information must be grouped by protection need so people know how carefully to handle it.
If information is classified, people need a practical way to see or infer the classification so they can handle it correctly.
The organization must define how information can be transferred safely, both internally and externally.
The organization must define and enforce rules for who can access information, systems, services, networks, applications, repositories, and physical locations.
Every user identity should be created, changed, reviewed, disabled, and removed through a controlled process.
The organization must control how secret authentication information is issued, changed, protected, reset, and handled.
Access rights must be granted, changed, reviewed, and removed through a controlled process.
The organization must manage information security risks created by suppliers, supplier products, and supplier services.
People must know what they are responsible for, and the organization must be able to prove those responsibilities were assigned, communicated, accepted, and kept current.
The organization must put the right security requirements into supplier contracts or agreements before the supplier receives access to information, systems, facilities, or services.
The organization must manage security risks that come through ICT suppliers and the suppliers behind those suppliers.
Supplier security does not end when the contract is signed. The organization must keep checking whether the supplier is delivering the agreed service securely, whether controls still work, and whether supplier changes create new risk.
No single person should be able to perform a sensitive activity from beginning to end without independent oversight, approval, review, or control.
Managers must actively ensure that people follow information security requirements.
The organization must know which external authorities matter for information security and must maintain usable contact paths before an incident, investigation, regulatory request, or emergency happens.
The organization should stay connected to credible external security knowledge sources. Security teams should not rely only on internal experience, vendor marketing, or outdated training.
The organization must collect threat information, analyze it in context, and turn it into usable intelligence for decisions.
Projects must handle information security from the start, not as a late review before go-live.
The organization must know what information and related assets it has, where they are, who owns them, how important they are, and how they are protected.
The organization should check that people are who they claim to be, have the relevant background for the role, and do not present unmanaged personnel risk before they join or receive access.
People should not have to guess what they are responsible for. Employment contracts, contractor agreements, confidentiality agreements, onboarding acknowledgements, or security responsibility addenda should clearly state what personnel must do to protect information and what the organization is responsible for.
People need to know how to behave securely in their actual role. Everyone needs baseline awareness, but people with specific responsibilities need deeper training that matches their work, systems, information access, and security duties.
The organization needs a documented and communicated process for handling information security policy violations. People should know that violations can lead to action, and managers should know how to trigger the process fairly and consistently.
When someone leaves the organization or changes role, their old access, assets, and responsibilities must be handled deliberately. Some rights should stop immediately. Some duties, such as confidentiality, may continue after the relationship ends.
The organization should know when confidentiality or non-disclosure agreements are needed, use terms that match its information-protection needs, keep those agreements legally usable, review them regularly, and make sure the right parties sign them before receiving confidential information.
When people work away from organization premises, the organization still has to protect information. That includes homes, hotels, coffee shops, customer sites, temporary offices, shared workspaces, and other remote locations.
People need to know what might be a security event, how to report it, who to report it to, and what not to do. Reporting should be fast, simple, and no-blame enough that people do not hide mistakes.
Cables are part of the information processing environment. If they are badly routed, unprotected, mixed incorrectly, poorly labelled, or accessible to unauthorized people, they can cause outages, interference, safety issues, interception, or tampering.
Equipment that runs reliably today can still fail tomorrow. The organization should define maintenance needs, follow supplier recommendations, use authorized maintainers, keep maintenance and fault records, and protect confidential information during maintenance.
Before equipment is reused, sold, returned, repaired, donated, recycled, or discarded, the organization should verify that sensitive information and licensed software are no longer recoverable.
The organization should control storage media from the moment it is obtained until it is erased, destroyed, disposed of, or transferred. Media includes digital and physical carriers such as USB drives, backup tapes, disks, removable drives, CDs/DVDs, printed records, and other portable media.
Information processing facilities need supporting utilities to operate. Electricity, cooling, ventilation, telecommunications, water, fire protection, emergency lighting, and building management systems can all affect availability.
The organization should protect equipment, documents, data, software, and storage media when they leave the organization's controlled environment.
The organization should place and protect equipment in a way that reduces physical damage, environmental damage, unauthorized access, unauthorized use, and information exposure.
The organization should know which physical areas need protection and where the boundaries are. A perimeter can be a building boundary, floor, room, cage, cabinet, loading area, reception barrier, secure office, server room, records archive, or customer-specific zone.
If an area is secure, entry should be controlled. The organization should know who is allowed in, how entry is verified, how visitors are handled, how delivery/loading areas are controlled, and how access records are reviewed.
The organization should design and implement physical protections for offices, rooms, and facilities based on what those areas contain and how critical or sensitive the work is.
The organization should monitor premises for unauthorized physical access, similar to how networks are monitored for intrusion. Monitoring may be manual, automated, or a mix of both.
The organization should protect sites, buildings, rooms, and infrastructure from hazards such as fire, flood, explosion, chemical leaks, civil unrest, utility failure, and threats from neighboring premises.
The organization should define how people work inside secure areas when the work itself is sensitive or critical. Physical entry controls are not enough. The rules must also cover what people may know, bring in, take out, record, discuss, supervise, and modify while inside the secure area.
People should not leave sensitive papers, removable media, printed documents, fax messages, or unlocked screens exposed where unauthorized people can see, photograph, remove, alter, or discard them.
Query-first control card for A.8.1 User End Point Devices. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.10 Information Deletion. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.11 Data Masking. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.12 Data Leakage Prevention. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.13 Information Backup. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.14 Redundancy of Information Processing Facilities. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.15 Logging. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.16 Monitoring Activities. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.19 Installation of Software on Operational Systems. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.2 Privileged Access Rights. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.20 Networks Security. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.21 Security of Network Services. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.22 Segregation of Networks. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.23 Web Filtering. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.24 Use of Cryptography. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.25 Secure Development Life Cycle. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.26 Application Security Requirements. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.27 Secure System Architecture and Engineering Principles. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.28 Secure Coding. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.29 Security Testing in Development and Acceptance. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.3 Information Access Restriction. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.30 Outsourced Development. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.31 Separation of Development Test and Production Environments. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.32 Change Management. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.33 Test Information. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.34 Protection of Information Systems During Audit Testing. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.4 Access to Source Code. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.5 Secure Authentication. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.6 Capacity Management. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.7 Protection Against Malware. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.8 Management of Technical Vulnerabilities. Use the linked detailed note for mentor-style implementation and audit guidance.
Query-first control card for A.8.9 Configuration Management. Use the linked detailed note for mentor-style implementation and audit guidance.
Section
4 notes across 1 subsections
Monthly review record documenting relevant threats, advisories, indicators, affected assets, and follow-up actions.
Record showing which indicators of compromise were received, assessed for relevance, and added to detection or blocking workflows.
Record showing a SIEM rule, detection query, alert condition, or correlation rule updated because of relevant threat intelligence.
Record showing vendor advisories reviewed for relevance to organizational assets, exposures, and risk treatment.
Section
2 notes across 2 subsections
This guide is the ISO/IEC 27005 view of the vault. It will grow as you provide more risk-management material.
ISO/IEC 27005 gives guidance for managing information security risk in support of an ISO/IEC 27001 ISMS. It helps turn risk thinking into a repeatable process for deciding what...
Section
6 notes across 1 subsections
A responsibility-aware map from GDPR obligations to ISO 27001 governance and Annex A controls without treating ISO certification as proof of GDPR compliance.
This table maps each covered A.5 organizational control to implementation output, audit evidence, and ISO/IEC 27005-style risk logic.
- A.6 controls are people-risk treatments. They reduce the chance that the wrong person is trusted or that the right person lacks clear obligations. - A.6 evidence often sits ou...
- Physical controls often fail through behavior, not technology. Observation and walkthrough evidence matter. - Physical controls should align to asset inventory, classification...
- A.8 controls require technical evidence. Policies are not enough. - Endpoint controls connect to remote working, off-premises assets, and incident reporting. - Privileged acce...
1. implementer view: what to build; 2. auditor view: what to verify; 3. ISO/IEC 27005 view: what risk logic supports the decision.
Section
41 notes across 1 subsections
- Screening must be lawful, ethical, proportional, and risk-based. - Screening applies to employees, contractors, temporary staff, and third-party users in ISMS scope. - Candida...
A.6.3 Information Security Awareness Education and Training asks whether the right people receive the right security knowledge at the right time, with updates when things change.
- A.6.4 requires a formalized and communicated disciplinary process, not ad hoc manager action. - A.6.4 should be evidence-based, fair, consistent, and proportionate. - A.6.5 co...
- Remote working is broader than VPN or remote access. - Remote work controls include physical environment, endpoint, secure connection, access, asset inventory, user awareness,...
- A.7.1 is about defined and used security perimeters. - A.7.2 is about entry controls and access points for secure areas. - Physical controls protect confidentiality, integrity...
- A.7.3 is risk-based physical design for offices, rooms, and facilities. - A.7.3 includes avoiding visible clues to sensitive targets, such as server-room signs or exposed dire...
- A.7.5 is not just fire safety; it covers physical and environmental threats to infrastructure. - A.7.5 should link to risk assessment, specialist advice, and business continui...
- A.7.8 is broader than server room protection. - Equipment siting includes workstations, network devices, terminals, screens, communications equipment, and remote equipment. -...
- A.7.9 is not only remote access. It includes equipment, documents, data, software, paper, mobile devices, BYOD, custody, and return. - A.7.9 allows risk acceptance where off-s...
- A.7.11 is not only electricity. - UPS or generator existence is weak unless capacity, runtime, maintenance, and tests match documented requirements. - Cooling must be included...
- A.7.12 is not just tidy cable management; it covers interception, interference, and damage. - A.7.13 is not only availability; maintenance can expose data or introduce tamperi...
- A.8.1 is not just anti-malware or laptop encryption. - BYOD is in scope when it accesses organizational information. - VPN does not solve endpoint security by itself. - A.8.2...
- A.8.4 includes development tools and software libraries, not only Git repositories. - Read access to source code can still be sensitive because it reveals system design and co...
- Antivirus installation alone is not enough. - Malware risk is not limited to Windows endpoints. - User awareness is explicitly part of the control. - Automatic cleaning still...
- A.8.8 is not just scanning or patching. - Vulnerability remediation should be risk-based and verified by retest. - Penetration testing supplements vulnerability management; it...
- A.8.10 is not only physical media destruction. - Retention policy alone is weak without deletion evidence. - Items awaiting destruction still need protection. - Masking is not...
- DLP is not just a tool. - DLP requires knowing sensitive data and approved flows. - False positives affect DLP effectiveness. - Backup job success is not restore success. - Ba...
- A.8.14 does not require full redundancy for every system. - Backup is not the same as redundancy. - Cloud resilience still needs design and testing evidence. - A.8.15 is not o...
- Treating log collection as full monitoring. - Assuming vendor default detection rules are sufficient. - Treating every alert as an incident without triage. - Ignoring monitori...
- Treating developer skill as a substitute for production change control. - Assuming emergency production changes do not need records. - Treating licence and support checks as u...
- Treating provider service use as provider-owned risk. - Treating uptime SLAs as full network service security. - Treating perimeter firewalls as sufficient segregation. - Assu...
- Assuming encryption alone satisfies the control. - Ignoring key lifecycle management. - Treating public keys and certificates as needing no integrity protection. - Selecting s...
- Treating secure SDLC as only code scanning. - Treating acquired applications as outside application security requirements. - Treating architecture principles as generic slogan...
- Treating secure SDLC as identical to secure coding. - Treating automated tools as complete proof of secure coding. - Treating functional testing as security testing. - Leaving...
- Assuming a supplier contract alone satisfies outsourced development control. - Treating supplier security as fully delegated. - Accepting supplier deliverables based only on f...
- Treating approval alone as full change management. - Treating emergency changes as exempt from control. - Treating test data as low risk because it is outside production. - Ig...
These controls are easy to confuse because both involve retained information. The exam distinction is purpose: records protection is about preserving required records; privacy/P...
These controls close the A.5 organizational control set by checking whether the ISMS is independently reviewed, whether policies and standards are followed, and whether operatin...
The exam often tests whether you understand the difference between mandatory management-system requirements and risk-selected controls.
The Statement of Applicability explains which Annex A controls apply, which do not, why those decisions were made, and whether selected controls are implemented.
ISO/IEC 27002 attributes help categorize controls by properties such as control type, information security properties, cybersecurity concepts, operational capabilities, and secu...
The exam may use policy, procedure, guideline, and standard loosely. Answer based on function, not title.
Roles and responsibilities must be defined, communicated, accepted, and kept current. Managers remain accountable for ensuring security requirements are followed in their area.
The exam often tests the difference between intent, documentation, and operating evidence.
Control type matters because risk treatment should match the desired risk effect.
Supplier and cloud controls overlap in practice, but the exam often tests the distinction between supplier risk management, contractual requirements, supply chain dependencies,...
The access-related controls form a chain: define access rules, manage identities, protect authentication secrets, and grant/review/remove actual access rights.
Incident management planning defines roles, reporting paths, escalation, communications, evidence handling, recovery coordination, and lessons learned before an incident occurs.
A.5.24 to A.5.28 form a practical lifecycle for incident management. Each control tests a different part of the lifecycle.
A.5.29 and A.5.30 are related but not interchangeable. One protects security during disruption; the other ensures ICT availability and recovery capability.
These controls are compliance-heavy. The exam may test whether the organization can prove obligations are known, current, owned, mapped to controls, and evidenced.
Section
2 notes across 2 subsections
ISO/IEC 27001 is the requirements standard. It defines the management-system requirements, the risk-based control selection requirement, and Annex A as the control reference set...
This map keeps the ISO/IEC 27001 requirement view separate from the implementer and auditor views.
Section
3 notes across 2 subsections
ISO/IEC 27002 provides guidance for information security controls. In this KB, it supports interpretation of ISO/IEC 27001 Annex A controls, evidence expectations, implementatio...
This map separates the ISO/IEC 27002 interpretation layer from the ISO/IEC 27001 requirement layer.
This note explains how ISO/IEC 27002 control attributes should be used in this KB.
Section
1 notes across 1 subsections
ISO/IEC 27005 is the risk-management companion for this project. It supports ISO/IEC 27001 implementation by making risk context, risk assessment, risk treatment, residual risk,...
Section
3 notes across 2 subsections
This section turns the ISO learning notes into a future compliance/evidence software model.
This section holds reusable risk knowledge for ISO/IEC 27005-style analysis and future GRC software modeling.
This note defines the practical data chain for the KB and future software model.
Section
6 notes across 1 subsections
How Articles 24, 25, 30, and 35 become ownership, processing records, design gates, DPIAs, and reviewable evidence.
How to select and document a lawful basis, apply Article 5 principles, control consent, and stop purpose or retention drift.
A practical control model for Article 28 contracts, processor due diligence, subprocessor changes, transfer safeguards, and service exit.
A practical starting point for deciding whether GDPR applies, identifying controller and processor roles, and turning legal scope into system ownership.
A risk-based Article 32 control model and an evidence-driven workflow for assessing, recording, notifying, and learning from personal-data breaches.
An operational guide to privacy notices, identity verification, access, correction, deletion, restriction, portability, and objections.
Section
332 notes across 9 subsections
Use this during internal audits to verify that acceptable use and handling rules are defined, acknowledged, implemented, and enforced.
Use this during internal audits to verify that assets are returned during termination, contract end, agreement end, or role change.
Use this during internal audits to verify that information classification is defined, implemented, understood, and maintained.
Use this during internal audits to verify that information labelling procedures are defined and implemented in line with the classification scheme.
Use this during internal audits to verify that information transfer rules, procedures, and agreements are defined and implemented across actual transfer channels.
Use this during internal audits to verify that physical and logical access controls are defined, implemented, approved, and reviewed.
Use this during internal audits to verify that identities are managed across the full lifecycle.
Use this during internal audits to verify that secret authentication information is allocated and managed through a controlled process.
Use this during internal audits to verify that access rights are provisioned, reviewed, modified, and removed according to access control rules.
Use this during internal audits to verify that supplier information security risks are identified, assessed, controlled, and reviewed.
Use this during internal audits to verify that supplier security requirements are formally agreed and appropriate to the supplier relationship.
Use this during internal audits to verify that ICT supply-chain dependencies and inherited security risks are identified and managed.
Use this during internal audits to verify that supplier services and security practices are monitored, reviewed, evaluated, and changed through a controlled process.
Use this during internal audits to verify that cloud services are acquired, used, managed, and exited according to information security requirements.
Use this during internal audits to verify that incident management planning and preparation are defined, communicated, and ready to operate.
Use this during internal audits to test whether A.5.25 Assessment and Decision on Information Security Events is designed, implemented, operating, and evidenced.
Use this during internal audits to test whether A.5.26 Response to Information Security Incidents is designed, implemented, operating, and evidenced.
Use this during internal audits to test whether A.5.27 Learning from Information Security Incidents is designed, implemented, operating, and evidenced.
Use this during internal audits to test whether A.5.28 Collection of Evidence is designed, implemented, operating, and evidenced.
Use this during internal audits to test whether A.5.29 Information Security During Disruption is designed, implemented, operating, and evidenced.
Use this during internal audits to test whether A.5.30 ICT Readiness for Business Continuity is designed, implemented, operating, and evidenced.
Use this during internal audits to test whether A.5.31 Legal, Statutory, Regulatory and Contractual Requirements is designed, implemented, operating, and evidenced.
Use this during internal audits to test whether A.5.32 Intellectual Property Rights is designed, implemented, operating, and evidenced.
Use this during internal audits to test whether A.5.33 Protection of Records is designed, implemented, operating, and evidenced.
Use this during internal audits to test whether A.5.34 Privacy and Protection of PII is designed, implemented, operating, and evidenced.
Use this during internal audits to test whether A.5.35 Independent Review of Information Security is designed, implemented, operating, and evidenced.
Use this during internal audits to test whether A.5.36 Compliance with Policies, Rules and Standards for Information Security is designed, implemented, operating, and evidenced.
Use this during internal audits to test whether A.5.37 Documented Operating Procedures is designed, implemented, operating, and evidenced.
Use this during internal audits to test whether relevant authority contacts are identified, maintained, authorized, and usable.
Use this during internal audits to verify that the organization maintains relevant external security knowledge contacts and uses received information appropriately.
Use this during internal audits to verify that threat information is collected, analyzed, contextualized, and used to support ISMS decisions.
Use this during internal audits to verify that information security is embedded in project governance and applied to sampled projects.
Use this during internal audits to verify that information and associated assets are inventoried, owned, maintained, and protected.
Research note.
Research note.
Research note.
Research note.
- Confirm the organization has a documented screening procedure. - Confirm screening applies to employees, contractors, temporary staff, and third-party users in ISMS scope. - C...
Use this checklist during an internal audit of employment, contractor, and third-party security responsibility terms.
Use this checklist during an internal audit of information security awareness, education, training, and update processes.
Use this checklist during an internal audit of disciplinary handling for information security policy violations.
Use this checklist during an internal audit of leaver, mover, contractor offboarding, and continuing responsibility controls.
Use this checklist during an internal audit of confidentiality and non-disclosure agreement controls.
- Confirm remote working policy and procedures exist. - Confirm authorized remote workers, locations, activities, data, and controls are recorded. - Check remote working risk as...
Use this checklist during an internal audit of information security event reporting.
- Confirm physical security perimeters are defined. - Confirm zones are linked to information/assets and risk. - Review perimeter diagrams or zone register. - Walk the perimeter...
Use this checklist during an internal audit of storage media acquisition, use, transport, storage, disposal, destruction, and damaged-media handling.
Use this checklist during an internal audit of power, cooling, telecommunications, water, emergency lighting, fire protection, and building-management utility resilience.
Use this checklist during an internal audit of power, data, telecommunications, and supporting service cabling.
Use this checklist during an internal audit of equipment maintenance and repair controls.
Use this checklist during an internal audit of equipment disposal, reuse, sale, donation, recycling, or repair dispatch.
- Confirm secure areas are identified. - Confirm entry controls match risk and sensitivity. - Review physical access authorization and logs. - Check physical access review recor...
Use this checklist during an internal audit of physical security design for offices, rooms, and facilities.
- Confirm premises monitoring scope is documented. - Confirm monitoring is continuous where required. - Review monitoring service or personnel responsibilities. - Check alarm re...
Use this checklist during an internal audit of physical and environmental threat protection.
Use this checklist during an internal audit of work performed inside secure areas.
Use this checklist during an internal audit of clear desk, clear screen, printer, fax, and unattended information controls.
Use this checklist during an internal audit of equipment siting, physical protection, environmental exposure, and remote equipment scope.
Use this checklist during an internal audit of assets taken, used, stored, or accessed outside organization premises.
Use this record to show business, system owner, and security approval of application security requirements.
Use this record when approving or validating tools used for audit testing, scanning, extraction, or assurance activities on operational systems.
Use this record when a system cannot meet the secure authentication standard and needs risk acceptance or compensating controls.
Use this matrix to connect business availability requirements to redundancy, backup, capacity, and continuity controls.
Use this record to prove backup restore capability was tested without compromising live data.
Use this review where building management systems are in ISMS scope or can affect information processing facilities.
Use this review for internal or external certificate authorities, public-key certificates, TLS certificates, signing certificates, and certificate lifecycle checks.
- Access control impact reviewed. - Logging/monitoring impact reviewed. - Backup/recovery impact reviewed. - Vulnerability or configuration impact reviewed. - Supplier or integr...
Use this record when configuration monitoring identifies drift from an approved baseline.
Use this record when a system cannot comply with an approved configuration baseline and the deviation needs risk-based approval.
Use this when encryption, digital signatures, electronic communications, key management, or cross-border services may be affected by legal or regulatory rules.
Use this record before sending damaged media for repair, manufacturer return, warranty replacement, disposal, or destruction.
Use this log to record DLP alerts, false positives, prioritization, tuning decisions, and escalation.
Use this record when temporary elevated access, remote support control, third-party troubleshooting, or dynamic privilege is granted to access information or functions.
Use this record when an urgent operational or security situation requires a change outside the normal approval cycle.
Use this record when emergency or break-glass privileged access is issued or used.
Use this template when placing, reviewing, relocating, or risk-assessing equipment that processes, stores, transmits, or displays information.
Use this when evidence related to an information security event may need to support investigation, legal action, regulatory response, disciplinary action, insurance, or formal r...
Use this to document ICT continuity requirements, recovery priorities, RTO/RPO expectations, test results, and improvement actions.
Use this to record incident response decisions, actions, approvals, communications, evidence decisions, containment, recovery, and closure.
Use this to maintain the inventory required by A.5.9 for information and associated assets, including owners, custodians, classification, location, backup/recovery, retention, a...
Use this to define the minimum information security requirements that must remain in place during disruption, crisis response, disaster recovery, or business continuity events.
Use this form to report observed or suspected information security events or weaknesses.
Use this record to document log review, alert triage, security impact assessment, escalation, and closure.
Use this attestation for assets assigned off-premises for an extended period, such as home-worker equipment or long-term project equipment.
Use this record when internal or external personnel perform maintenance on equipment that can affect information security.
Use this record when malware is suspected or confirmed and the organization needs evidence of detection, containment, cleaning/rebuild, verification, and lessons learned.
Use this record to review whether monitoring thresholds create useful alerts without hiding real incidents or overwhelming the response team.
Use this map to prove which networks, systems, applications, cloud services, and security tools feed the monitoring process.
Use this record to review firewall, router, switch, VPN, wireless, SD-WAN, load balancer, or virtual network device configuration and changes.
Use this review before contracting, renewing, or materially changing a network service.
Use this assessment to determine physical security controls for offices, rooms, and facilities based on the information and assets inside them.
Use this record for each approved software installation or update on operational systems.
Use this acknowledgement during onboarding, contractor setup, role change, or access expansion to record acceptance of security responsibilities.
Use this template to assess site, building, room, utility, and neighboring-premises hazards that could affect information assets or ICT continuity.
Use this template to review physical access rights for secure areas, badges, keys, cards, PINs, or biometric access.
Use this record to document tests of physical alarms, monitoring services, notification chains, and escalation response.
Use this assessment when data is claimed to be anonymised or when combinations of fields may still identify individuals.
Use this record to prove failover or redundancy testing met availability requirements.
Use this template to assess remote working risk for a role, location type, activity, system, or information classification.
Use this record to document secure code review, reviewer independence, findings, and remediation.
Use this record when secure coding rules cannot be fully applied because of legacy constraints, technology limits, or justified operational need.
- Acceptance criteria are met or exceptions approved. - High-risk findings are closed or formally accepted. - Operations readiness is confirmed. - User/security training is comp...
Use this record to document architecture review against secure engineering principles.
Use this record when a system design deviates from approved secure architecture or engineering principles.
Use this tracker to record security test findings, remediation, retesting, and residual risk acceptance.
Use this record for individual or group training evidence. Avoid storing unnecessary personal data in the vault if HR systems hold the authoritative record.
Use this record when sensitive information needs to be transferred outside normal approved flows or to an external party.
Use this checklist to review whether signs, directories, phone lists, notice boards, or visible labels reveal sensitive targets or access information.
Use this to reconcile software, development tools, libraries, subscription content, and licensed resources against actual use.
Use this log when storage media is removed, transported, couriered, archived, delivered, or returned.
Use this list when preparing an internal audit, supplier review, or acceptance review for outsourced development.
Use this before onboarding or materially changing a supplier relationship, and during periodic supplier review.
Use this to record periodic supplier reviews, security report reviews, service delivery issues, supplier changes, incidents, and follow-up actions.
Use this log to record inspections, tests, maintenance, alarms, and corrective actions for supporting utilities.
Use this when reviewing whether a selected control matches the intended risk treatment effect.
Research note.
Use this to track nonconformities, audit findings, policy violations, or control weaknesses.
Research note.
Use this for roles with significant information security responsibilities, such as system owner, asset owner, administrator, incident manager, vendor owner, or risk owner.
- Where can you find the information security policy? - What are your main information security responsibilities? - How do you report a suspected security incident? - What secur...
- What are your information security responsibilities? - How do you ensure your team follows information security policies? - How do you know your team completed required traini...
Use this in manager role descriptions, policy addenda, or management training packs.
Use this to link risks, treatment objectives, controls, control attributes, owners, and evidence.
- What are your basic information security responsibilities? - Where can you find the information security policy? - How do you report a suspected incident? - What should you do...
Use this as an addendum to job descriptions, employee handbooks, contractor onboarding packs, or role profiles.
Use this when full segregation of duties is not practical and compensating controls are required.
Research note.
Use this record before production or sensitive data is copied into development, test, staging, analytics, or supplier environments.
Use this record to verify whether UPS and generator capacity matches the documented availability and continuity requirements.
Use this checklist when reviewing virtual networks, cloud networks, hypervisors, security groups, route tables, virtual firewalls, or management planes.
Research note.
Use this record when a vulnerability will not be remediated within the normal timeframe and requires risk-based exception approval.
Use this review to verify that web filtering applies to required users, devices, locations, remote-working scenarios, and network paths.
Use this assessment when wireless networks connect to organizational networks or provide access to business systems.
Use this when creating an ISO/IEC 27001 clause note under the ISO 27001 knowledge base.
Use this when creating a reusable control card that maps ISO/IEC 27001 Annex A, ISO/IEC 27002 guidance, ISO/IEC 27005 risk logic, evidence, audit questions, and software objects.
Use this when defining an evidence item for an audit, control, risk treatment, or future GRC data model.
markdown type: risk-scenario asset: "" threat: "" vulnerability: "" risk level: "" likelihood: "" impact: "" treatment option: "" related controls: evidence required: owner: ""...
Use this at the end of each study week to keep learning, artifacts, mappings, and weak areas connected.
- Review endpoint policy and device security standard. - Confirm endpoint inventory includes corporate and BYOD devices. - Sample endpoint compliance reports. - Check patch, mal...
Use this checklist during an internal audit of retention, deletion, destruction, cloud deletion, backup deletion, and media awaiting destruction.
Use this checklist during an internal audit of masking, pseudonymisation, tokenisation, anonymisation, re-combination, and re-identification controls.
Use this checklist during an internal audit of DLP scope, data flows, DLP rules, alert handling, transfer approvals, and user awareness.
Use this checklist during an internal audit of backup scope, schedule, protection, job monitoring, restore testing, archive recoverability, and corrective action.
Use this checklist during an internal audit of redundancy requirements, architecture, failover testing, recovery performance, and redundancy-related risk.
Use this checklist during an internal audit of log generation, storage, protection, retention, analysis, alerting, and corrective action.
Use this checklist during an internal audit of security monitoring, alerting, anomaly detection, triage, escalation, and incident evaluation.
Use this checklist during an internal audit of software installation, release, testing, licence, support, and rollback controls for operational systems.
Use this checklist during an internal audit of privileged access allocation, use, monitoring, emergency access, and removal.
Use this checklist during an internal audit of network architecture, device security, zoning, routing, virtual networks, monitoring, and change control.
Use this checklist during an internal audit of network service security mechanisms, service levels, service requirements, provider controls, and monitoring.
Use this checklist during an internal audit of network zones, inter-zone controls, wireless segregation, segmentation tests, and exceptions.
Use this checklist during an internal audit of web filtering policy, tool configuration, coverage, exceptions, bypass resistance, monitoring, and awareness.
Use this checklist during an internal audit of cryptographic policy, approved algorithms, key management, certificate handling, legal requirements, and escrow/recovery.
Use this checklist during an internal audit of secure development rules, competence, code review, vulnerability follow-up, and supplier development.
Use this checklist during an internal audit of application security requirements for developed or acquired applications.
Use this checklist during an internal audit of secure architecture and engineering principles.
Use this checklist during an internal audit of secure coding principles, standards, tools, reviews, generated code, and exceptions.
Use this checklist during an internal audit of security testing in development and acceptance.
Use this checklist during an internal audit of application, database, report, export, print, maintenance utility, and dynamic privilege access restrictions.
- Outsourced development scope is identified. - Supplier development risk assessment exists. - Contract/SOW includes security requirements. - IP ownership and licence obligation...
Use this checklist when auditing separation of development, test, staging, and production environments.
Use this checklist when auditing change management for information systems and information processing facilities.
Use this checklist when auditing selection, protection, management, and deletion of test information.
Use this checklist when auditing protection of operational systems during audit testing and assurance activities.
Use this checklist during an internal audit of source code, development tools, software libraries, and code-impacting scripts or macros.
Use this checklist during an internal audit of authentication mechanisms, MFA, failed logon controls, recovery flows, and authentication exceptions.
Use this checklist during an internal audit of resource monitoring, trend analysis, capacity forecasting, scaling, tuning, and staffing capacity.
Use this checklist during an internal audit of malware protection deployment, update status, scanning, infection response, and user awareness.
Use this checklist during an internal audit of vulnerability intelligence, scanning, risk evaluation, remediation, patching, exceptions, and retesting.
Use this checklist during an internal audit of secure configuration baselines, implementation, monitoring, exceptions, and review.
Use this for periodic reviews of logical or physical access to systems, repositories, applications, networks, cloud platforms, and sensitive locations.
Use this checklist when code, scripts, infrastructure-as-code, tests, or configuration snippets are generated by AI or other automated code-generation tools.
Use this before externally using AI-generated or AI-assisted material in policies, templates, consulting deliverables, training, marketing, software, or client work.
Use this checklist for applications that perform payments, customer transactions, public-network transactions, or legally significant actions.
Use this when an employee, contractor, third-party user, or other relevant party leaves, changes role, ends a contract, or no longer requires organizational assets.
Use this checklist during design review, audit preparation, or system assessment to test whether authentication behavior is secure.
Use this checklist during hiring, contractor onboarding, or role change into a higher-risk position.
Use this checklist during physical walkthroughs to verify cabling is protected from interception, interference, damage, and unsafe installation.
Use this checklist for routine clear desk and clear screen inspections, especially in shared offices, visitor-exposed areas, and areas handling sensitive information.
Use this checklist when verifying deletion of information from cloud services, backups, archives, snapshots, or replicated storage.
Use this before acquiring a cloud service, during periodic cloud review, and before exiting or migrating from a cloud provider.
Use this checklist to review NDA/confidentiality agreement needs, content, signing, enforceability, and review status.
Use this checklist to compare systems against approved configuration baselines and record compliance gaps.
Use this checklist for periodic review of capacity risks in critical systems, cloud services, networks, databases, and support teams.
Use this checklist to control deliveries, collections, loading bays, and goods movement into or out of secure areas.
Use this checklist to review whether development, test, staging, and production separation is real and enforceable.
Use this checklist to review compilers, build tools, CI/CD runners, package sources, dependency registries, and library integrity controls.
Use this checklist when reviewing whether the disciplinary process can fairly handle information security policy violations.
Use this checklist when a laptop, phone, tablet, or other endpoint device is lost, stolen, or suspected compromised.
Use this checklist during site walkthroughs to confirm physical and environmental protections remain effective.
Use this checklist during physical walkthroughs to confirm equipment is still sited securely and protected from damage, interference, unauthorized access, and unauthorized viewing.
Use this checklist before equipment containing storage media is reused, sold, donated, recycled, discarded, or transferred outside organizational control.
Use this checklist to test whether application, database, reporting, export, and maintenance access restrictions match approved access rules.
Use this checklist when cryptographic keys must be recoverable for legal, operational, continuity, or organizational control reasons.
Use this checklist for employee leavers, contractor offboarding, third-party user removal, and internal role changes.
Use this checklist to review whether logs are protected against unauthorized modification, deletion, redirection, shutdown, and overwrite.
Use this checklist to verify that archived information can still be read and interpreted for legal, regulatory, or business retention requirements.
Use this checklist when designing or reviewing user awareness content for malware prevention and reporting.
Use this checklist to test that network zone boundaries block and allow traffic as intended.
Use this checklist during periodic review of supplier-provided network services.
Use this checklist when approving, reviewing, or auditing assets used away from organization premises.
Use this when creating, reviewing, or changing operating procedures for information processing facilities.
Use this checklist to define and test how monitoring alerts are handled outside normal business hours.
Use this checklist before signing or renewing a development contract, statement of work, or supplier delivery plan.
Use this checklist before applying patches where testing, change approval, outage planning, or rollback is required.
Use this checklist during physical security reviews, office moves, layout changes, tenancy changes, or internal audits.
Use this to review whether PII handling, access, transfer, retention, and training controls remain appropriate.
Use this checklist to review whether printers and fax machines expose sensitive information through location, unattended output, or weak secure-printing practices.
Use this to test whether privacy breach notification obligations are known and can be acted on quickly. Verify specific legal deadlines and content requirements against official...
Use this checklist during periodic reviews of privileged users, privileged roles, emergency access, and stale access.
Use this checklist to review privileged account activity logs for appropriate, authorized, and traceable use.
Use this for the documented annual check that required records still exist, remain protected, and remain accessible through retention.
Use this checklist to verify that endpoints connecting remotely meet security requirements before accessing organizational systems.
Use this checklist before approving remote work or during periodic review of remote working controls.
Use this checklist before sending equipment for repair, warranty return, vendor analysis, or replacement.
Use this checklist to verify code against the applicable secure coding standard.
Use this checklist to verify that a project or development team follows secure development rules.
Use this checklist to define the security conditions that must be met before a system is accepted for operational use.
Use this checklist when reviewing employment contracts, contractor terms, onboarding acknowledgements, or security addenda for A.6.2 coverage.
Use this checklist when reviewing whether sensitive application functions, reports, downloads, exports, and print features are restricted according to access rules.
Use this checklist before acquiring or installing software on operational systems, and during periodic review of supported operational software.
Use this checklist before installing software on operational systems where failure could affect confidentiality, integrity, availability, or business service.
Use this checklist when reviewing whether code, scripts, macros, reports, and database logic changes are controlled before release.
Use this before signing or renewing supplier agreements where the supplier has access to information, systems, facilities, services, or security-relevant dependencies.
Research note.
Use this to verify whether managers are actively enforcing security requirements in their teams.
Use this during planned policy reviews or event-driven reviews after significant changes.
Use this checklist before and after testing that involves sensitive, production-derived, personal, or confidential information.
Use this when sensitive information or software is exchanged with suppliers, customers, partners, regulators, contractors, or other third parties.
Use this to document access requests, approvals, provisioned rights, reviews, modifications, and removals.
Use this register to document security requirements for developed, acquired, or changed applications.
Use this register to document approved sensitive data transfers, channels, protections, and authorization requirements.
Use this to document and maintain official authority contacts required for incident response, breach notification, continuity, legal compliance, sector regulation, or emergency...
Use this register to confirm that important information, software, systems, configurations, and dependencies are covered by backups.
Use this register to document important power, data, and supporting service cable routes and the protection applied to them.
Use this register to record capacity metrics, trends, forecasts, thresholds, and planned actions.
Use this to track approved cloud services, ownership, data exposure, shared responsibility, review status, and exit readiness.
Use this register to track confidentiality and non-disclosure agreements for employees, contractors, temporary staff, third-party users, suppliers, partners, visitors, and other...
Use this register to record approved configuration baselines and map them to systems, platforms, services, and networks.
Use this register to track cryptographic keys, owners, purpose, storage, lifecycle dates, rotation, revocation, and destruction.
Use this register to document where cryptography is used and whether the chosen algorithm, protocol, and key parameters are appropriate.
Use this register to record where masking, pseudonymisation, tokenisation, or anonymisation is used and why.
Use this register to define sensitive information in DLP scope and map DLP rules to systems, channels, and devices.
Use this register to track user endpoint devices, custodians, ownership model, and security compliance.
Use this register to track equipment disposal, reuse, sale, donation, recycling, repair dispatch, or transfer where storage media or licensed software may be present.
Use this register to track equipment maintenance requirements, completed maintenance, fault history, and replacement indicators.
Use this to record reported information security events and the decision on whether each event is an information security incident.
Use this for critical ICT products and services where subcontractors, cloud platforms, hosting providers, software components, support parties, or other dependencies may affect...
Use this to track identity creation, changes, reviews, deactivation, deletion, and shared-identity exceptions.
Use this after incidents or recurring events to capture what changed in controls, training, procedures, risk assessment, supplier management, or management review.
Use this register to record deletion or destruction of information, systems, storage media, backups, and cloud data.
Use this register to document approved event reporting channels, contact points, responsibilities, and availability.
Use this to track protected software, documents, designs, source code, trademarks, patents, subscription content, and other intellectual property material used or created by the...
Use this to identify, document, assign, review, and evidence legal, statutory, regulatory, and contractual information security requirements.
Use this register to track log sources, event types, retention periods, protection methods, and review ownership.
Use this register to track malware protection deployment, update status, scan settings, and exceptions across systems.
Use this register to translate risks and threat scenarios into concrete monitoring rules, alerts, thresholds, and response actions.
Use this register to record network faults, suspicious events, monitoring alerts, problem records, and corrective actions.
Use this register to define required security mechanisms, service levels, and service requirements for network services.
Use this register to authorize and track organization assets, information, software, or media taken outside controlled premises.
Use this to inventory operating procedures, owners, versions, approvals, users, and review dates.
Use this register to track ongoing supplier development reviews, issues, and acceptance decisions.
Use this register to track whether screening was completed for employees, contractors, temporary staff, and third-party users before joining or receiving sensitive access.
Use this register to track repeated false alarms and corrective actions that prevent alarm fatigue.
Use this register to define physical security zones, their purpose, protected assets, access routes, and perimeter controls.
Use this to track management compliance reviews, spot checks, technical compliance checks, findings, actions, and follow-up.
Use this register to track security policy violation cases, evidence review, decision, outcome, and closure.
Use this register to track security responsibilities that continue after termination, contract end, or role change.
Use this register to record privileged accounts, roles, approvals, scope, expiry, and review status.
Use this for projects that build, buy, configure, integrate, outsource, or materially change systems, services, processes, suppliers, infrastructure, or data flows.
Use this to identify required records, retention periods, protection requirements, storage locations, access restrictions, readability dependencies, and disposal rules.
Use this register to map availability requirements to implemented redundancy for critical information processing facilities.
Use this register to track equipment outside core premises, including branch, remote, home-office, customer-site, or supplier-hosted equipment within ISMS responsibility.
Use this register to track who is authorized to work remotely, from what location type, for which activities, with which data, equipment, and controls.
Use this register to track who is authorized to access secure areas and when physical access rights should be reviewed or removed.
Use this register to record approved sensitive work, authorized personnel, supervision needs, device restrictions, and dual-control requirements inside secure areas.
Use this register to record erasure, destruction, disposal, contractor handoff, and verification for storage media that may contain organizational information.
Use this register to record source repositories, access rights, owner approvals, and periodic review status.
Use this to track the specialist security groups, forums, associations, advisories, and communities the organization uses to keep security knowledge current.
Use this as the master security view of suppliers, products, and services that can affect information security.
Use this register to map critical facilities, services, and equipment to required supporting utilities and continuity expectations.
Use this to map ISMS processes and controls to accountable owners, responsible teams, evidence, and review cycles.
Use this to track policy ownership, approval, version control, review, and acknowledgement requirements.
Use this register to track test data sets, their source, sensitivity, approval, protection, retention, and deletion.
Use this to record threat information that has been reviewed, contextualized, and converted into intelligence for risk, control, incident response, vulnerability, or management...
Use this tracker to record vulnerabilities, exposure, owners, treatment actions, due dates, retests, and closure.
Use this register to record approved web filtering exceptions, false positives, and business-required access to otherwise blocked categories.
Use this to define standard access rights by role, asset, classification, and approval owner.
Use this matrix to track security training expectations for developers, reviewers, DevOps, testers, and architects.
Use this to assign incident response roles, escalation contacts, communications responsibilities, and decision authority before an incident happens.
Use this matrix when defining or reviewing role-based access to an application, service, database, report set, or information repository.
Use this to define classification levels, handling rules, labelling expectations, owner responsibilities, and review rules for information assets.
Use this to define which transfer methods are approved for each information classification and what controls must be used.
- Zone owner identified. - Allowed flows are specific. - Broad rules are justified. - Sensitive paths are monitored. - Rules are reviewed periodically.
Use this to document PII holdings and map privacy protections back to legal, regulatory, and contractual requirements.
Use this matrix to map training requirements to roles, responsibilities, systems, and information access.
Use this when a supplier relationship has shared security responsibilities and the contract needs a clear split between the organization, the supplier, and any shared control ar...
Research note.
Use this to identify incompatible duties and document whether they are segregated or covered by compensating controls.
Use this matrix to map web filtering policy decisions to blocked, warned, allowed, monitored, and exception-handled categories.
Use this as a practical rules template for personnel, contractors, and third-party users who use organizational information and associated assets.
Use this record before audit tests, scans, assurance checks, or tool-assisted reviews are performed on operational systems.
Use this to define how passwords, PINs, recovery answers, MFA tokens, biometric authentication data, privileged credentials, and service secrets are issued, handled, reset, and...
Use this template to define backup frequency, scope, retention, storage location, protection, and restore testing requirements.
Use this plan to define how critical systems and services will be monitored, trended, forecast, and adjusted for capacity.
Use this procedure to define how changes to systems, infrastructure, applications, code, networks, cloud resources, and operational environments are controlled.
Use this policy to define approved cryptographic uses, algorithms, protocols, key management responsibilities, legal checks, and exceptions.
Use this standard to define masking, pseudonymisation, tokenisation, anonymisation, full-data access, and re-identification controls.
Use this standard to define the minimum security expectations for development, test, staging, and production environments.
Use this standard to define the minimum security baseline for user endpoint devices before they access organizational information.
Use this to define how information security events, weaknesses, and incidents are reported, triaged, investigated, escalated, recovered from, reviewed, and improved.
Use this to plan and record independent reviews of the information security management approach and implementation.
Use this template to define retention periods, deletion triggers, deletion methods, and evidence requirements by information type.
Use this standard to define loggable events, minimum log fields, retention, protection, review, and escalation requirements.
Use this standard to define minimum malware protection requirements for endpoints, servers, mobile devices, cloud workloads, email, web access, file uploads, and removable media.
Use this standard to document network zones, trust boundaries, sensitive traffic paths, management networks, public exposure, and virtual/cloud network scope.
Use this procedure to define how software, packages, libraries, patches, tools, and vendor updates are approved and installed on operational systems.
Use this procedure template to define how premises are monitored for unauthorized physical access.
Use this plan for significant releases or grouped changes before operational implementation.
Use this standard to document the secure engineering principles that system development activities must apply.
Use this procedure template to define how sensitive work is performed inside secure areas.
Use this standard to define minimum authentication expectations for applications, operating systems, remote access, privileged access, and third-party access.
Use this standard to define secure coding principles and language/framework-specific rules.
Use this policy to define mandatory secure development rules for internal teams, contractors, and suppliers.
Use this plan to define annual, induction, refresher, and role-specific information security training.
Use this plan to define risk-based security testing during development and before acceptance.
Use this procedure to define how storage media is acquired, approved, labelled, used, stored, transported, erased, destroyed, and disposed of.
Use this before running configuration checks, vulnerability scans, firewall reviews, cloud configuration reviews, penetration tests, or other technical conformity checks.
Use this to prove that relevant personnel and interested parties were informed of policies and acknowledged them where required.
Use this to draft or review the organization's high-level information security policy under A.5.1 Policies for Information Security.
Use this procedure to define how the organization identifies, evaluates, treats, retests, and reports technical vulnerabilities.
Section
5 notes across 3 subsections
Research note.
Research note.
Research note.
Research note.
Research note.
Section
6 notes across 1 subsections
markdown type: audit question question id: "" question: "" related standard: ISO27001 related clause: "" related controls: related risks: expected evidence: status: draft answer...
markdown type: clause standard: ISO27001 clause id: "" clause name: "" status: not started priority: medium related iso27005 topics: related iso27002 topics: related controls: r...
Use this for ISO 27001 Annex A controls that should appear in Dataview dashboards.
markdown type: evidence evidence id: "" evidence name: "" evidence type: "" status: draft related standard: ISO27001 related controls: related risks: owner: "" source system: ""...
markdown type: exam topic standard: ISO27001 topic: "" status: not started confidence: low confidence rank: 1 exam relevance: medium exam relevance rank: 2 weak area: true relat...
Use this for ISO 27005-style risk scenarios that should appear in Dataview dashboards.
Try clearing the framework filter.