EDUCATION, ORGANISATIONAL SECURITY

🏛️ Organisational security

Organisational controls include management, process and human level security mechanisms - policies, roles, risk management, suppliers, incidents and compliance. They constitute a framework in which technical and physical controls work meaningfully. Basically ISO/IEC 27001 Management System (ISMS) and ISO/IEC 27002 Chapter 5 (37 controls). Examples are fictional, designed for training.

Legend: codes as 5.3 refers to the control of Chapter 5 (organic) of ISO/IEC 27002:2022. kl. 4-10 = ISO/IEC 27001 clauses (ISMs requirements).

What are organisational controls

ISO 27002:2022 four control topics - Organisationally highlighted

ISO 27002:2022 control topics Four ISO 27002:2022 control topics. Organisational controls (Chapter 5, 37 controls) are highlighted. ISO/IEC 27002:2022 - 4 control topics Organisational chapter 5, 37 controls ← this section Staff chapter 6, 8 controls Physical chapter 7, 14 controls Technological chapter 8, 34 controls ISO 27001 Annex A combines all 93 controls, organizational is the largest theme (40%)

Organisational = management controls: they determine how the organisation manages security - policies, roles, risk decisions, contracts, processes. Unlike technical (in-built) and physical (environment and access), the organisation is based on management commitment and processes.

Management

Senior management determines the direction, allocates resources and assumes responsibility for security (ISO 27001 clause 5). Without the management commitment, the remaining controls remain formal.

Process based

Organisational controls are recurring processes - risk assessment, access review, incident handling, supplier evaluation - not one-off settings.

Relationship with NIS2 and regulatory acts

Article 21 of the NIS2 and national legislation require management measures: risk policies, roles, security of the supply chain, handling of incidents and continuity - these are all organisational controls.

ISO/IEC 27001 - Management system

ISMS and PDCA - Continuous Improvement Cycle

PDCA cycle for ISMS management Plan-Do-Check-Act cycle around the ISMS centre, with ISO 27001 clauses divided by phases. ISMS - Plan, Do, Check, Act (continuous improvement) ISMS 4-10 Plan - planned context, risk assessment target, SoA, kl. 4-6 Do - Introduce control, resources, consciousness activity 7-8 Check - Check monitoring, internal audit management review, kl. 9 Act - improves non-compliances, correction improvement, cf.10

ISMS (Information Security Management System) is a continuous process, nor a project with an end. The PDCA cycle ensures that security adapts to new threats and changes. ISO 27001 clauses 4-10 have minimum requirements for certification.

Plan - Context and Risk (C.4-6)

Defines the organisation context and stakeholders, the scope of ISMS, management leadership and safety objectives. Risk assessment and application declaration (SoA).

Do - introduces (kl. 7-8)

Provides resources, expertise and understanding, documented information and communication. The risk assessment and treatment shall be carried out in practice by introducing the controls chosen.

Check and Act (kl. 9-10)

Monitoring, measurement, internal audit and management review shall assess effectiveness. Non-compliance corrects the causes and improves the system continuously (continual improvement).

Additional governance frameworks: ISO 27001 is not alone. COBIT and SABSA complement this - they are used together, not as alternatives, depending on the organisation's maturity and objectives.

COBIT 2019 (ISACA)

IT governance framework. A clear distinction is made between governance (EDM - Evaluate, Direct, Monitor; Council/managing level) and management (APO, BAI, DSS, MEA domains). 40 objectives. Places information security in the wider IT management of the company and helps to match it with business goals and demonstrate it to management.

SABSA

Business-led, risk-based security architecture methodology. SABSA matrix: 6 layers (from contextual to operational) × 6 questions (which, why, who, where, when). Every security control traceable to business requirement - eliminates 'security security after'.

TOGAF (The Open Group)

Company architecture framework with ADM - structured process for business, data, applications and technology architecture. Security architecture (SABSA) shall be included as an element that runs through the entire architecture, so that security is built into design, not added later.

How they fit together

ISO 27001 defines ISMS and controls (KAS and CIK good), COBIT adds an IT management view (how to manage and coordinate with business), SABSA and TOGAF provide an architectural method of converting requirements into controls (how to design). NIST CSF serves as a common mapping layer between them.

International practice

ISO/IEC 27002:2022 Chapter 5 - 37 organisational controls

thematic groups on controls in chapter 5 37 organisational controls are grouped into seven thematic groups, from management to compliance. 37 controls - 7 thematic groups Governance, policies 5.1-5.8 Asset management 5.9-5.14 Access, identity 5.15-5.18 Suppliers, cloud 5.19-5.23 Incident management 5.24-5.28 Continuity 5.29-5.30 Compliance, legal 5.31-5.37
5.1Information security policies
5.2Security roles and responsibilities
5.3Segregation of duties
5.4Management responsibilities
5.5Contacts with institutions
5.6Contacts with interest groups
5.7Threat Intelligence
5.8Security in project management
5.9Inventory of assets
5.10Acceptable use of assets
5.11Return of assets
5.12Classification of information
5.13Labelling of information
5.14Transmission of information
5.15Access control
5.16Identity management
5.17Authentication information
5.18Access rights
5.19Security in supplier relations
5.20Security in suppliers' contracts
5.21Security in the ICT supply chain
5.22Supervision of suppliers' services
5.23Security in cloud services
5.24Incident planning and preparation
5.25Evaluation of events and decisions
5.26Response to incidents
5.27Learning From Incidents
5.28Collection of evidence
5.29Safety during malfunction
5.30ICT readiness for continuity
5.31Legal and regulatory requirements
5.32Intellectual property rights
5.33Protection of recordings
5.34Privacy and R & D & I protection
5.35Independent safety review
5.36Consistency with policies and standards
5.37Documented operational procedures

Link to ISO 27001 Annex A

ISO 27002 provides guidance on the implementation of each control. ISO 27001 Annex A lists the same controls as the reference list for the declaration of applicability (SoA).

Attribute (new 2022)

Each control in the 2022 version has attributes (control type, security feature CIA, cybersecurity concept, operational capabilities, security domains) for filtering and mapping against other frameworks.

Not all mandatory

Controls shall be selected on the basis of a risk assessment, not mechanically. The SoA shall justify which shall apply and which shall exclude and why it shall constitute the basic audit document.

ISO 27001 kl. 6 / ISO 27005

Risk management - from assessment to declaration of applicability

Risk management process Process from context through risk assessment and treatment to declaration and acceptance of applicability. Risk management (ISO 27005 process) Context scope, criteria Identify asset, threat Analyse probability × effect Evaluate with an appetite SoA applicability declaration Risk Treatment - 4 Options Reduce introduce controls Share insurance, contract Avoid ceases operation Accept deliberate decision The residual risk is confirmed by the risk owner risk management plan, monitoring, periodic reassessment (PDCA)

Application declaration (SoA) is the central document of ISO 27001: it lists all controls of Appendix A, indicates which apply and which are excluded and justifies each decision against the risk assessment. The auditor starts from SoA.

Risk Holder

Each risk is named owner - person with authority and responsibility to make a processing decision and confirm the residual risk. Without the owner the risk remains unmanaged.

Appeasement and criteria

The organisation shall define in advance the risk acceptance criteria. This makes the evaluation consistent and reproducible, not dependent on the individual valuer's point of view.

Continuous repetition

The picture of risks is changing - new threats, systems, suppliers. The assessment shall be repeated in a planned manner and after significant changes or incidents, not only once during certification.

ISO 5.1 / 5.2 / 5.3 / 5.37

Policy hierarchy, roles and responsibilities

Policy hierarchy and segregation of responsibilities On the left, the pyramid of documents from policy to guidelines; the principle of the right separation of duties. Documents hierarchy and segregation of duties Policy - WHAT AND WHY (management confirms) Standards - minimum requirements Procedures - HOW step by step (5.37) Guidelines - recommendations (optional) top less, uncommon changes Segregation of duties (5.3) Request change Confirmed other person Implementation third party no person controls the entire operating cycle → reduces the risk of fraud and error small teams - compensatory controls (journals, reports)

Policy ≠ procedure: policy defines direction and responsibility (approved management), procedure describes concrete steps. Documented operating procedures (5.37) ensure that critical tasks are performed consistently independently of the performer.

Roles and responsibilities (5.2)

Security roles are clearly defined and assigned - who is responsible for what (e.g. RACI matrix). Senior management takes the main responsibility. Every employee knows his or her security role.

Lifecycle of policies (5.1)

Policies are approved by management, published and communicated to employees, reviewed planned and after significant changes. Obsolete, unknown policies are as bad as their absence.

Segregation of duties (5.3)

Conflicting responsibilities are shared between people so that no one can abuse or hide a mistake. Where this is not possible (small teams), compensatory controls are introduced.

ISO 519-5.30 / 5.31-5.37

Suppliers, incidents, continuity and compliance

Life cycle of incident management Six-step incident management cycle from preparation to learning, with a return to the beginning. Incident management cycle (5.24-5.28) 1. Prepare plan, roles 2. Discover report, register 3. Evaluate classification, priority 4. Respond restricted, eliminated 5. Recover restore operation 6. Learn post-mortem (5.27) training returns to plan - improves preparedness Article 23 NIS2: Early warning within 24 hours, incident notification within 72 hours (to be provided by national legislation) evidence collection (5.28) - preserve chain where legal action is required

Management of suppliers (5.19-5.23): security requirements are incorporated into contracts, the risk assessment of suppliers, the monitoring of service changes and in particular the management of the ICT supply chain and cloud services. For more details, the "Supply Chain Security" guide.

Continuity (5.29 / 5.30)

Safety shall also be maintained during malfunction. ICT for Continuity (BCP/DRP) with recovery targets (RTO/RPO), tested by training, provides access to crisis.

Compliance (5.31-5.34)

Identify legal, regulatory and contractual requirements (GDPR, NIS2, national and international laws and regulations), protect entries, intellectual property and personal data (PII). Compliance is a continuous obligation, not one-off.

Independent review (5.35 / 5.36)

Safety is periodically reviewed independently (internal/external audit) and managers check compliance with policies in their area. It detects discrepancies before being used by attackers.

Compliance in Latvia - the main requirement is national laws and regulations: National laws and regulations are mandatory regulations in Latvia that determine what is mandatory (in the national cyber security framework, implementing NIS2). Implementing Regulation (EU) 2024/2690 and GDPR complement the requirements. International standards (ISO 27001/27002, COBIT, SABSA, TOGAF, NIST) provide a recognised auditable method for their implementation.

Levels of compliance - from EU law to implementation Three layers: EU legal basis (NIS2, Implementing Regulation 2024/2690, GDPR), national legislation and international enforcement standards (ISO, COBIT, SABSA, TOGAF, NIST). From requirement to implementation: law defines KO, standards - VU EU LEGAL BASIS NIS2 Directive (EU) 2022/2555 Implementing Regulation (EU) 2024/2690 DGPR (EU) 2016/679 transposed nationally National Cybersecurity Law and its subordinates WHAT to do is mandatory, national cybersecurity legal framework introduced by recognised standards INTERNATIONAL IMPLEMENTATION STANDARDS - HOW ISO 27001 / 27002 COBIT SABSA TOGAF NIST CSF / 800-53

Regulatory acts shall determine the result to be achieved. The international standard is a verifiable way to achieve it - without it compliance remains declarative.

Regulatory acts - mandatory requirement

Latvia's binding regulation sets out minimum organisational measures: risk management, security policy, incident handling and continuity. Implementation is based on ISO 27001 ISMS and governance frameworks (COBIT, TOGAF).

Implementing Regulation (EU) 2024/2690

Detailed measures for Article 21 of the NIS2 The Annex requires security policy, risk management policy, incident handling, operational continuity and supply chain security - direct organisational controls (ISO 27002 Chapter 5).

GDPR - personal data

GDPR (EU 2016/679) requires personal data protection and accountability. ISO 27002 5.34 (Privacy and PII) and 5.31-5.33 (Legal requirements, record and IP protection) are organisational implementation.

Abbreviations

Abbreviations used in the Roadmap: the original name and what it means.

ISMS
Information Security Management System - information security management system (ISO 27001).
SoA
Statement of Applicability - declaration of applicability - which controls apply and why.
PDCA
Plan-Do-Check-Act - plans - do - check - improves.
RACI
Responsible, Accountable, Consulted, Informed - a matrix defining who makes, who replies, who consults and who is informed.
COBIT
ISACA IT governance framework.
EDM / APO / BAI / DSS / MEA
COBIT domains: governance; planning; implementation; operation; monitoring.
SABSA
Sherwood Applied Business Security Architecture - business-led security architecture method.
TOGAF / ADM
The Open Group Architecture Framework / Architecture Development Method - the architecture framework of the company and the method of its development.
CIA
Confidentiality, Integrity, Availability - confidentiality, integrity, accessibility.
BCP / DRP
Business Continuity Plan / Disaster Recovery Plan - continuity plan/recovery plan.
RTO / RPO
Recovery Time / Point Objective - permissible idle time/tolerable loss of data.
PII
Personally Identifiable Information - personal data.