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, intended for teaching.

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 kontroļu tēmas Četras ISO 27002:2022 kontroļu tēmas. Organizatoriskās kontroles (5. nodaļa, 37 kontroles) ir izceltas. ISO/IEC 27002:2022 - 4 kontroļu tēmas Organizatoriskās nodaļa 5 · 37 kontroles ← šī sadaļa Personāla nodaļa 6 · 8 kontroles Fiziskās nodaļa 7 · 14 kontroles Tehnoloģiskās nodaļa 8 · 34 kontroles ISO 27001 Pielikums A apvieno visas 93 kontroles · organizatoriskās ir lielākā tēma (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 to NIS2 and MK 397

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

ISO/IEC 27001 - Management system

ISMS and PDCA - Continuous Improvement Cycle

PDCA cikls ISMS pārvaldībā Plan-Do-Check-Act cikls ap ISMS centru, ar ISO 27001 klauzulu sadalījumu pa fāzēm. ISMS - Plan · Do · Check · Act (nepārtraukta uzlabošana) ISMS kl. 4-10 Plan - plāno konteksts · risku novērtēšana mērķi · SoA · kl. 4-6 Do - ievies kontroles · resursi · apziņa darbība · kl. 7-8 Check - pārbaudi monitorings · iekšējais audits vadības pārskats · kl. 9 Act - uzlabo neatbilstības · koriģēšana uzlabošana · kl. 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, competence and awareness, 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-driven, 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 integrated as a cross-sectional aspect so that security is built into the design, not later added.

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

5. nodaļas kontroļu tematiskās grupas 37 organizatoriskās kontroles sagrupētas septiņās tematiskās grupās - no pārvaldības līdz atbilstībai. 37 kontroles - 7 tematiskās grupas Pārvaldība · politikas 5.1-5.8 Aktīvu pārvaldība 5.9-5.14 Piekļuve · identitāte 5.15-5.18 Piegādātāji · mākonis 5.19-5.23 Incidentu pārvaldība 5.24-5.28 Nepārtrauktība 5.29-5.30 Atbilstība · juridiskā 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

Risku pārvaldības process Process no konteksta caur risku novērtēšanu un apstrādi līdz piemērojamības deklarācijai un pieņemšanai. Risku pārvaldība (ISO 27005 process) Konteksts tvērums · kritēriji Identificēt aktīvi · draudi Analizēt varbūtība × ietekme Izvērtēt pret apetīti SoA piemērojamības deklarācija Riska apstrāde - 4 opcijas Mazināt ievieš kontroles Pārnest apdrošināšana · līgums Izvairīties pārtrauc darbību Pieņemt apzināts lēmums Atlikušo risku (residual risk) apstiprina riska īpašnieks risku apstrādes plāns · uzraudzība · periodiska atkārtota novērtēšana (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

Politiku hierarhija un pienākumu nošķiršana Kreisajā pusē dokumentu piramīda no politikas līdz vadlīnijām; labajā pienākumu nošķiršanas princips. Dokumentu hierarhija un pienākumu nošķiršana Politika - KO un KĀPĒC (vadība apstiprina) Standarti - obligātās prasības Procedūras - KĀ soli pa solim (5.37) Vadlīnijas - ieteikumi (nav obligāti) augšā mazāk, retāk mainās Pienākumu nošķiršana (5.3) Pieprasa izmaiņu Apstiprina cita persona Ievieš trešā persona neviena persona nekontrolē visu darbības ciklu → samazina krāpšanas un kļūdu risku mazās komandās - kompensējošās kontroles (žurnāli, pārskati)

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

Incidentu pārvaldības dzīves cikls Sešu soļu incidentu pārvaldības cikls no sagatavošanās līdz mācīšanās, ar atgriešanos uz sākumu. Incidentu pārvaldības cikls (5.24-5.28) 1 · Sagatavoties plāns · lomas 2 · Atklāt ziņot · reģistrēt 3 · Izvērtēt klasificēt · prioritāte 4 · Reaģēt ierobežot · izskaust 5 · Atgūt atjaunot darbību 6 · Mācīties post-mortem (5.27) mācības atgriežas plānā - uzlabo sagatavotību NIS2 23. pants: būtisku incidentu agrīns brīdinājums CERT.LV 24 h laikā, ziņojums 72 h laikā pierādījumu vākšana (5.28) - saglabā ķēdi, ja nepieciešama tiesiska rīcība

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, MK 397), 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 - main requirement MK 397: Cabinet Regulations No.397 is the binding regulation in Latvia, which determines what must be done (in the national cybersecurity framework, implementing the 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.

Atbilstības slāņi - no ES tiesībām līdz ieviešanai Trīs slāņi: ES tiesiskais pamats (NIS2, Īstenošanas regula 2024/2690, GDPR), Latvijas saistošā prasība MK 397, un starptautiskie ieviešanas standarti (ISO, COBIT, SABSA, TOGAF, NIST). No prasības līdz ieviešanai: MK 397 nosaka KO, standarti - KĀ ES TIESISKAIS PAMATS NIS2 direktīva (ES) 2022/2555 Īstenošanas regula (ES) 2024/2690 GDPR (ES) 2016/679 transponē nacionāli MK noteikumi Nr. 397 - Latvijas saistošā prasība KO obligāti jāizdara · nacionālais kiberdrošības tiesiskais ietvars ievieš ar atzītiem standartiem STARPTAUTISKIE IEVIEŠANAS STANDARTI - KĀ ISO 27001 / 27002 COBIT SABSA TOGAF NIST CSF / 800-53

MK 397 determines the result required by law. The international standard is a verifiable way to achieve it - without it compliance remains declarative.

MK 397 - National 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.