Governance, Frameworks and Compliance

Governance and management

Security governance is the system by which an organization directs and controls its security: top management decides what the organization wants to protect, how much risk it is willing to accept (its risk appetite), who is responsible for what, and how progress is checked. Security management then plans, builds, runs and monitors the measures within that direction. Governance asks "are we doing the right things?"; management asks "are we doing things right?".

The distinction matters because security decisions are business decisions. Whether a factory may keep running an unsupported control system for another year, or whether a new customer portal can go live before its penetration test, is a question of risk and money. The IT department can advise, but someone with authority over the business has to decide and be accountable. Risk itself is explained in Threats, Vulnerabilities and Risk.

Roles and responsibilities

A common split of roles, whatever the exact job titles in your organization:

The chief information security officer (CISO) is the senior manager responsible for an organization's information security program. The CISO is responsible for running the program, but the risk decisions stay with the business: a CISO who silently "accepts" risks on behalf of the organization hides them from the people who should decide. Many organizations place the CISO outside the IT line, reporting to the board or a risk function, so that security concerns about IT can be raised independently. Smaller organizations often combine the role with another one, or hire a part-time ("virtual") CISO.

Policies, standards, procedures, guidelines

Governance becomes concrete in documents. They form a hierarchy: each level is more detailed, changes more often and is approved lower in the organization than the one above it.

A security policy is a high-level, management-approved statement of what the organization requires for security and why. It is deliberately short and technology-neutral, so it survives a change of email provider or firewall vendor. The top-level information security policy usually states the goals, the scope, the roles and the consequences of violations; topic policies (acceptable use, access control, backup, incident response) sit under it.

A security standard (in this sense: an internal document) turns a policy into specific, mandatory requirements that can be checked: "passwords have at least 15 characters", "laptops use full-disk encryption", "servers are patched within 14 days of a critical update". The numbers are an example; your organization chooses its own. A baseline is a related idea: the minimum secure configuration for one type of system. Do not confuse internal standards with published standards such as ISO/IEC 27001 — the word is used for both.

Policies also need a life cycle: an owner, a review date (often yearly or after a major change), version control, and an exception process. When a system cannot meet a standard, the deviation is requested, its risk assessed, accepted by the risk owner for a limited time, and recorded. An undocumented exception is simply a violation.

Security frameworks

Nobody has to invent a security program from scratch. A framework is a published, structured set of practices or controls that organizations use to build, measure and explain their security. When a framework is also used to demonstrate that requirements are met, often through an independent audit, it is called a compliance framework. Frameworks give you a checklist of what to consider, a common language with auditors and partners, and a way to measure progress.

NIST Cybersecurity Framework 2.0

The NIST Cybersecurity Framework (CSF), published by the United States National Institute of Standards and Technology (NIST), is a voluntary framework that organizes cybersecurity outcomes into high-level functions, categories and subcategories. Version 2.0 appeared in February 2024. It was originally written for critical infrastructure; 2.0 explicitly addresses organizations of every size and sector, and many European organizations use it alongside ISO/IEC 27001.

Two more ideas from the CSF are useful in practice. Profiles describe a current state and a target state, so the gap between them becomes a work plan. Tiers (Partial, Risk Informed, Repeatable, Adaptive) describe how mature and integrated an organization's risk management is. The detailed controls behind the outcomes come from elsewhere, for example NIST SP 800-53 or ISO/IEC 27002; the CSF provides mappings to them.

ISO/IEC 27001 and 27002

ISO/IEC 27001 is the international standard that specifies the requirements for an information security management system (ISMS): the set of policies, processes, roles and controls with which an organization manages information security risk and keeps improving. It is the standard organizations are certified against. The current edition is ISO/IEC 27001:2022.

The main clauses (4 to 10) describe the management system itself, in a plan–do–check–act cycle: understand the context and scope, get leadership commitment, assess and treat risks, provide resources and awareness, operate the controls, measure and audit, and improve. The controls come from Annex A: in the 2022 edition, 93 controls grouped into four themes.

An organization does not have to implement every control. After its risk assessment it writes a Statement of Applicability (SoA) that lists each Annex A control, whether it applies, and why or why not. ISO/IEC 27002 is the companion guidance: it explains the same 93 controls in detail with implementation advice. You cannot be certified against 27002; it is a guide, 27001 is the requirement.

Certification is done by an accredited certification body. A first audit usually has two stages — a review of the documentation, then a check that the ISMS works in practice. A certificate is typically valid for three years, with surveillance audits in between. When you rely on a supplier's certificate, read its scope: a certificate for "the data center in Amsterdam" says nothing about the supplier's software development.

CIS Controls

The Center for Internet Security (CIS) Critical Security Controls are a prioritized list of practical safeguards: 18 controls in version 8 (updated to 8.1 in 2024), from "inventory and control of enterprise assets" to "penetration testing". Their strength is prioritization. Implementation Group 1 (IG1) is the set of safeguards described as essential cyber hygiene for every organization; IG2 and IG3 add more for organizations with more resources and higher risk. For a small organization that does not know where to start, IG1 is a sensible first target. CIS also publishes the CIS Benchmarks: secure configuration guides for specific operating systems and products.

Sector frameworks

Many sectors build on ISO/IEC 27001 or national baselines with their own requirements:

International standards apply in every region:

• IEC 62443 is a series of standards for the security of industrial automation and control systems, relevant to energy, water and manufacturing.
• PCI DSS applies to anyone handling payment card data (see Cloud Security and Compliance).

Cybersecurity law

Frameworks are chosen; laws are not. Since the early 2020s governments have turned several security practices into legal obligations, especially for critical sectors, for makers of digital products and for the financial sector. Personal data has its own laws, covered in Privacy and Data Protection.

Critical sectors and incident reporting

NIS2 is the European Union directive on measures for a high common level of cybersecurity across the Union (Directive (EU) 2022/2555), the successor of the 2016 Network and Information Systems (NIS) directive. The United Kingdom implemented the first version through the NIS Regulations 2018 and kept them after Brexit; the United States has no comparable law that covers all critical sectors, and relies on a patchwork of federal and sector rules.

Secure products

Financial sector

Audits

An audit is a systematic, independent examination of evidence to determine whether an organization meets a set of criteria, such as a policy, a standard or a law. Independence is the key word: auditors may not audit their own work.

• Internal audits are done by the organization's own audit function or by colleagues from another department. ISO/IEC 27001 requires them. They find problems early, before an external auditor or an attacker does.
• External audits are done by an outside party: a certification body, a regulator, a customer exercising its right to audit in a contract, or an accountant issuing an attestation report such as SOC 2 (System and Organization Controls).

Auditors work with evidence: documents (policies, the risk register), records (access review sign-offs, training completion, change tickets), system data (configuration exports, audit logs), interviews and observation. Because they cannot check everything, they take samples: "show me the approval for these five accounts created in March". If a control is done but leaves no trace, it cannot be shown to work — which is why procedures say "record it".

The result is a set of findings. Certification audits distinguish major nonconformities (a requirement is not met at all, or a control fails systematically; this blocks certification until fixed), minor nonconformities (an isolated lapse) and observations or opportunities for improvement. Each nonconformity gets a corrective action with an owner and a date, and the next audit checks that it was done.

Compliance is not security

Compliance means being able to show that you meet the requirements of laws, contracts and standards. It is valuable — it forces discipline and makes management pay attention — but it is not the same as being secure:

• An audit is a snapshot. The firewall rule review that was fine in March says nothing about the rule added in May.
• Requirements are a minimum, written for many organizations at once. Your specific threats may need more.
• A control can exist on paper and fail in practice: a backup policy is no use if restores were never tested (see Backup and Recovery).

The healthy direction is the other way around: manage your real risks well, and compliance mostly follows as a by-product, with evidence collected as part of normal work.

Mapping controls to a framework in Python

A common governance task is mapping the controls an organization already has to a framework, to see where the gaps are. This sketch maps a few controls of a fictional organization to the CSF functions and scores each function: implemented counts as 1, partial as 0.5, planned as 0.

FUNCTIONS = ["Govern", "Identify", "Protect", "Detect", "Respond", "Recover"]
SCORE = {"implemented": 1.0, "partial": 0.5, "planned": 0.0}

# (id, control, CSF function, status) — a fictional organization
CONTROLS = [
    ("POL-01", "Security policy approved by the board", "Govern", "implemented"),
    ("RSK-01", "Yearly risk assessment", "Govern", "partial"),
    ("AST-01", "Inventory of hardware and software", "Identify", "partial"),
    ("IAM-01", "MFA for all remote access", "Protect", "implemented"),
    ("IAM-02", "Quarterly access reviews", "Protect", "planned"),
    ("BAK-01", "Daily backups with an offline copy", "Protect", "implemented"),
    ("LOG-01", "Central logging of sign-ins", "Detect", "partial"),
    ("IR-01", "Incident response plan", "Respond", "implemented"),
]

print(f"{'Function':<10}{'Controls':>9}{'Score':>8}")
for function in FUNCTIONS:
    statuses = [c[3] for c in CONTROLS if c[2] == function]
    if not statuses:
        print(f"{function:<10}{0:>9}{'-':>8}   GAP: no controls mapped")
        continue
    score = sum(SCORE[s] for s in statuses) / len(statuses)
    print(f"{function:<10}{len(statuses):>9}{score:>8.0%}")

print("\nOpen items:")
for control_id, name, function, status in CONTROLS:
    if status != "implemented":
        print(f"  {control_id}  {status:<8} {name}")

Function   Controls   Score
Govern            2     75%
Identify          1     50%
Protect           3     67%
Detect            1     50%
Respond           1    100%
Recover           0       -   GAP: no controls mapped

Open items:
  RSK-01  partial  Yearly risk assessment
  AST-01  partial  Inventory of hardware and software
  IAM-02  planned  Quarterly access reviews
  LOG-01  partial  Central logging of sign-ins

The report shows the obvious gap — nothing at all for Recover — and also the limits of such a score. Respond scores 100% with one control, yet an incident response plan that was never exercised may not work. Backups count under Protect in CSF 2.0; Recover is about actually executing and verifying the recovery, which this organization has not planned. Real mappings go down to the category and subcategory level and are reviewed by people, not just counted.