Resources / Information Security and Data Privacy / Information Security in Practice

Introduction

Information security is not a technology problem. It is a governance, risk management, and organisational behaviour problem that happens to involve technology. Organisations that treat it purely as an IT matter consistently underinvest in the controls that matter most and are consistently surprised when things go wrong.

In regulated financial services, healthcare, and other sectors, the stakes are particularly high. The data held is sensitive. Regulatory expectations are demanding. The threat environment is genuinely sophisticated. Ransomware, supply chain attacks, and targeted social engineering all create failure modes that perimeter defences alone cannot address.

This guide is aimed at practitioners: compliance professionals, risk managers, programme managers, and senior leaders who need to understand what a functioning information security programme looks like from a governance and operational perspective. It is not a technical manual. It does not explain how to configure a firewall or deploy encryption software. What it covers is the framework, the controls that matter most in a regulated environment, and the governance decisions that determine whether those controls actually work.

The guide is built around ISO/IEC 27001:2022. For organisations that are certified, the transition from ISO/IEC 27001:2013 ended on 31 October 2025, so ISO/IEC 27001:2022 is now the certification basis. It also references the NIST Cybersecurity Framework (CSF) and the UK and New Zealand regulatory contexts, which shape what you need to do in practice. The aim is not to produce a compliance checklist. It is to give practitioners a working view of how effective information security programmes are built, resourced, and sustained.

The framework

What information security is trying to do

Information security has three core objectives, often described as the CIA triad: confidentiality, integrity, and availability. Confidentiality means that information is accessible only to those who are authorised to see it. Integrity means that information is accurate and has not been altered without authorisation. Availability means that systems and data are accessible when they are needed.

Most security incidents involve a failure in at least one of these three areas. A ransomware attack destroys availability. A data breach violates confidentiality. A corrupted database affects integrity. The controls that protect against each of these failures overlap significantly, but understanding which objective is at risk in a given scenario helps with prioritisation.

In a regulated organisation, a fourth objective is increasingly relevant: resilience. Not just whether you can prevent an attack, but whether you can continue to operate during one and recover from it without unacceptable loss of service or data. This is the focus of operational resilience frameworks, including DORA and the Bank of England's approach in the UK. The question has shifted from whether you will be breached to how quickly you will recover when you are.

ISO/IEC 27001:2022

ISO/IEC 27001 is the international standard for an information security management system (ISMS). It provides a framework for establishing, implementing, maintaining, and continually improving information security across an organisation. Certification can demonstrate to regulators, customers, and counterparties that the organisation is managing information security risk systematically.

The 2022 edition has been the sole valid version since 31 October 2025, following the end of the transition period from ISO/IEC 27001:2013. It made two significant changes. First, it restructured Annex A from 114 controls in 14 domains to 93 controls in four themes: Organisational, People, Physical, and Technological. Second, it added 11 new controls reflecting current risks, including threat intelligence, information security for cloud services, data leakage prevention, and ICT readiness for business continuity.

The standard is built around ten management clauses (4 through 10) that set out the requirements for operating and maintaining an ISMS. These clauses are largely unchanged from the 2013 version and cover context, leadership, planning, support, operation, performance evaluation, and improvement. The changes in 2022 were concentrated in Annex A.

ISO 27001 is not prescriptive about which controls must be implemented. It requires organisations to conduct a risk assessment, identify the controls needed to address the identified risks, and document in a Statement of Applicability which controls are included and why. This risk-based approach means the right set of controls for a large bank looks different from the right set for a small professional services firm, even if both are certified.

ISO 27001 certification is not a guarantee of security. It demonstrates that an organisation has a documented, maintained ISMS and that an independent auditor has assessed its controls. Certification requires annual surveillance audits and full recertification every three years. The value is in the ongoing discipline of the management system, not the certificate itself.

Other frameworks

ISO/IEC 27001 is not the only framework, and for many organisations it sits alongside others. The NIST Cybersecurity Framework (CSF), updated to version 2.0 in 2024, is widely used where there is US regulatory exposure or a US government connection. It organises security activities into six functions: Govern, Identify, Protect, Detect, Respond, and Recover. The addition of Governance as a core function reflects the same shift towards leadership accountability that ISO/IEC 27001:2022 embeds.

The Centre for Internet Security Critical Security Controls (CIS Controls) provide a more prescriptive approach, with 18 control groups prioritised by implementation effort and impact. They are useful for organisations that want practical guidance on where to start.

COBIT provides an IT governance and management framework that addresses information security alongside broader IT governance. It is relevant for organisations where the information security programme needs to integrate closely with IT governance structures.

For organisations with EU financial sector exposure, DORA sets specific requirements for ICT risk management, incident reporting, resilience testing, and oversight of third-party ICT providers. If you are in scope, treat DORA as a primary rule set and map your existing framework (ISO/IEC 27001, NIST CSF, internal policies) to its requirements. NIS2 may also apply depending on your activities and how your member state has implemented it, but DORA is the more specific operational resilience regime for financial services.

Governance and leadership

Information security programmes fail most often not because of inadequate technology but because of inadequate governance. The controls do not work if leadership does not own them, if accountability is unclear, and if security is treated as someone else's problem.

Board and executive ownership

ISO 27001:2022 is explicit: top management must demonstrate leadership and commitment to the ISMS. This is not a formality. It means the board and executive team need to understand the organisation's material information security risks, approve the security policy, ensure adequate resources are provided, and actively participate in management review.

In practice, most boards engage with information security through a risk committee or audit committee, receiving periodic reports from the CISO or equivalent. The quality of that engagement matters. A board that receives a traffic-light status report and asks no substantive questions is not providing meaningful oversight. A board that receives clear risk information, understands the threat environment, and holds management accountable for remediation is.

The questions boards should be asking are not technical. They are governance questions. What are our most significant information security risks, and are they within appetite? What has changed in the threat environment that we need to be aware of? Are the controls we have invested in working? What would a significant incident cost us, and are we prepared to manage the response? How dependent are we on third parties for critical functions, and what happens if one of them fails?

Roles and responsibilities

Clear ownership is a prerequisite for an effective security programme. The three lines of defence model applies to information security in the same way it applies to other risk disciplines.

The first line is the business: the operational units and technology teams that own and manage information assets day to day. They are responsible for implementing security controls in their own processes and systems, identifying and reporting security issues, and complying with security policy. Security cannot be delegated entirely to a central function. If the business does not own its security obligations, the controls will not work in practice.

The second line is the security function: typically the CISO and their team, plus the compliance and risk functions. They set the policy framework, provide expertise and guidance, monitor compliance, and report to senior management and the board on the programme's state. The Chief Information Security Officer should have direct access to the board and not be buried within the technology function without an independent reporting line.

The third line is internal audit, providing independent assurance that the controls exist, are designed appropriately, and are operating effectively. Regular security audits, including penetration testing and vulnerability assessments, are part of this picture.

The information security officer (or equivalent) needs to be distinguishable from the IT Director or CTO, in the same way the privacy officer is distinguishable from the Legal Director. The person responsible for security oversight should not be the same person responsible for building and maintaining the systems they are overseeing.

The information security policy

The information security policy is the foundational document that sets out the organisation's approach to managing information security risk. Under ISO 27001, it is a mandatory requirement and must be approved by top management.

An effective policy framework typically covers the organisation's overall approach to information security, the scope of the ISMS, roles and responsibilities, the risk assessment and treatment approach, the controls applied, incident management, and compliance with regulatory requirements. Policies should be written for the people who need to apply them. A long, legalistic document that staff cannot easily understand or use is not an effective control.

Core controls

The 93 controls in Annex A of ISO 27001:2022 cover a wide range of areas. Not all of them are equally relevant to every organisation. The following covers the controls that have the most practical impact in regulated environments, and where failures most commonly occur.

Access control and identity management

Unauthorised access to systems and data is one of the most common causes of security incidents. Access control is the primary preventive control.

The principle of least privilege means that users should have access only to the systems and data they need to perform their role, and no more. In practice, many organisations grant broad access at onboarding and never review it. Former employees retain access long after leaving. Privileged accounts accumulate over time. Regular access reviews are the control that addresses this, but they are only effective if someone is actually responsible for conducting them and acting on the findings.

Multi-factor authentication is now a baseline expectation, not a premium control. Any account with access to sensitive data or critical systems should require MFA. The 2022 Annex A controls include specific attention to authentication information management, reflecting the reality that password-only authentication is insufficient for most environments.

Privileged access management covers accounts with elevated permissions, such as system administrators and database administrators. These accounts represent higher risk and need tighter controls. That typically includes stronger authentication, session controls, just-in-time access, and regular review.

One of the 11 new controls in ISO 27001:2022 is Annex A 5.9, inventory of information and other associated assets. You cannot control access to what you do not know you have. A current, accurate asset inventory is the foundation of access control. Most organisations significantly underestimate the number of systems and data stores that hold sensitive information.

Threat intelligence

Annex A 5.7 in the 2022 edition introduces threat intelligence as a formal control: the collection and analysis of information about information security threats to support decision-making. This reflects the reality that reactive security, responding to incidents after they occur, is increasingly insufficient.

Threat intelligence in practice does not require a sophisticated in-house capability. It means subscribing to relevant feeds, monitoring publications from national cyber agencies (the UK NCSC, New Zealand's National Cyber Security Centre, and the ACSC in Australia), participating in sector information-sharing groups, and ensuring the intelligence is used to update controls and reassess risk.

For regulated financial services organisations, sector-specific threat intelligence is particularly valuable. Financial sector threats are well-documented by regulatory bodies and industry groups. The challenge is less about obtaining intelligence and more about having a process for translating it into action.

Incident response

Every organisation will experience a security incident. The question is whether it can detect it, contain it, and recover from it effectively. Building that capability before an incident occurs is the work of information security management. Building it during one is much more expensive.

An incident response plan needs to specify what constitutes a security incident and how it is reported internally, who is responsible for leading the response, how the incident is classified by severity, what actions are taken at each severity level, how external parties (including regulators, customers, and insurers) are notified, and how the incident is documented for post-incident review.

The plan needs to be tested. A tabletop exercise that walks the response team through a realistic scenario once a year is a minimum. The exercise should include the people who will actually make decisions during an incident: the CISO, legal, communications, and the executive team. Security operations teams should also conduct more frequent technical exercises.

The connection between incident response and breach notification is critical. If an incident involves personal data, it may trigger notification obligations under the GDPR or UK GDPR, the New Zealand Privacy Act 2020, or Australia's Notifiable Data Breaches scheme. For GDPR/UK GDPR, the 72-hour clock for notifying the supervisory authority runs from when the organisation becomes aware that a personal data breach has occurred. If your incident process does not include an early, explicit check to determine whether personal data is involved and a clean hand-off to the privacy lead, you will lose time fast.

Under DORA, in-scope EU financial entities must classify ICT-related incidents and report major incidents to their competent authority using the EU framework. In practice, that means your incident management process needs a DORA decision point: is this in scope, is it major, and who is responsible for the regulatory report?

Vulnerability management

Vulnerabilities in software and systems are identified continuously. Attackers exploit known vulnerabilities that organisations have not patched. A functioning vulnerability management programme identifies vulnerabilities across the organisation's systems and ensures they are remediated within a defined timeframe, based on severity.

The programme needs to cover all systems, not just the ones the IT team is most familiar with. Shadow IT, legacy systems, and third-party hosted systems are common blind spots. The asset inventory is the starting point: you cannot manage vulnerabilities in systems you do not know you have.

Penetration testing is a complementary control: an authorised simulated attack on the organisation's systems to identify vulnerabilities that automated scanning misses. Penetration tests should be conducted at least annually and after significant changes to the environment. DORA requires financial entities to conduct threat-led penetration testing periodically, which is a more intensive form of testing based on realistic threat intelligence.

Cloud security

ISO 27001:2022 includes a new control specifically addressing information security for cloud services (Annex A 5.23). This reflects the reality that most organisations now process, store, and transmit significant volumes of data through cloud services, and that the security model for cloud environments differs from that of traditional on-premises infrastructure.

The shared responsibility model is the central concept. Cloud providers are responsible for the security of the infrastructure; customers are responsible for the security of what they put into it. A poorly configured S3 bucket, an overly permissive API, or an unprotected data store is the customer's responsibility, not the cloud provider's. Many significant data breaches have resulted from misconfigurations that are entirely within the customer's control.

Cloud security controls include classifying data before deciding where it can be stored and processed, configuring appropriate access controls and encryption for cloud resources, reviewing cloud provider security certifications and shared responsibility documentation, monitoring cloud environments for anomalous access or configuration changes, and ensuring that cloud assets are included in the asset inventory and vulnerability management programme.

Data leakage prevention

Annex A 8.12 in the 2022 edition introduces data leakage prevention as a formal control. DLP refers to the technical and process controls that prevent sensitive data from being transmitted outside the organisation without authorisation, whether intentionally or accidentally.

The practical application covers controls on email to prevent sensitive data from being sent to external addresses, monitoring of file transfers and data uploads, endpoint controls to prevent data from being copied to removable media or personal cloud storage, and monitoring of the printing of sensitive documents.

DLP controls need to be calibrated carefully. Overly aggressive controls that block legitimate business activity will be worked around. Poorly configured controls that generate excessive alerts will be ignored. The right level of sensitivity depends on the organisation's data classification and the risk assessment.

Business continuity and ICT resilience

ISO 27001:2022 includes a control addressing ICT readiness for business continuity (Annex A 5.30). The connection between information security and business continuity is direct: a successful cyberattack is one of the most common causes of significant business disruption, and the ability to recover from one is as important as the ability to prevent it.

Business continuity planning for information security needs to address backup strategies that ensure critical data can be restored after a ransomware attack or system failure, recovery time objectives and recovery point objectives that reflect what the business can actually tolerate, alternative processing arrangements if primary systems are unavailable, and testing of recovery procedures, not just documentation of them.

Organisations regularly discover during an actual incident that their backups are incomplete, their recovery procedures do not work, or their RTOs are not achievable. Testing the plan before an incident is the only way to determine whether it works. This is not a comfortable exercise, but it is much less painful than discovering the gaps when systems are actually down.

Staff training and awareness

The human element is consistently cited as the most significant factor in security incidents. Phishing, social engineering, accidental data exposure, and poor password hygiene all involve human behaviour. Technology controls can reduce the risk, but they cannot eliminate it. Staff training and security awareness are primary controls, not supplementary ones.

Training needs to be relevant, practical, and regularly refreshed. A once-a-year module that staff click through without engaging is not effective. The most effective programmes combine regular short communications on current threats, role-specific training for high-risk functions, simulated phishing exercises to test and reinforce awareness, and visible senior leadership engagement with the security culture.

Simulated phishing exercises deserve specific mention. Running a controlled phishing simulation and measuring click rates provides real data on the organisation's human vulnerability. Following up with targeted training for those who clicked, rather than naming and shaming, turns the exercise into a learning opportunity. The click rate in simulations generally declines significantly over time with a sustained programme.

Third-party and supply chain risk

No organisation's information security programme exists in isolation. Most regulated organisations share data with, and depend on, a large number of third parties: technology vendors, cloud providers, payment processors, outsourced service providers, and professional advisers. Each of those relationships creates a risk exposure that the organisation is responsible for managing.

Supply chain attacks have become one of the most significant vectors for serious security incidents. Rather than attacking a large, well-defended organisation directly, attackers compromise a smaller supplier with access to the target's systems. The resulting incident can be more damaging than a direct attack because it is harder to detect and because it exploits the trust relationship between the organisation and its supplier.

ISO 27001:2022 addresses supplier security across multiple controls, and the 2022 edition specifically added a control covering security in the ICT supply chain (Annex A 5.21). The principle is straightforward: the organisation is responsible for the security of its information wherever it is held or processed, including at supplier premises.

Supplier assessment and due diligence

Security assessment of suppliers should happen before onboarding, not after. A supplier that cannot demonstrate how it protects the data it will access should not be given access. The depth of assessment should be proportionate to the risk: a supplier with access to large volumes of sensitive customer data needs a more rigorous assessment than one providing a non-critical administrative function.

Assessment typically covers the supplier's information security certifications (ISO 27001, SOC 2, or equivalent), their data protection policies and practices, their incident response and breach notification procedures, their subcontracting arrangements and how they manage their own supply chain, their business continuity and resilience capabilities, and their approach to access controls for the data they will hold.

Certification is useful evidence but not conclusive. ISO 27001 certification means the supplier has a documented ISMS that has been audited. It does not mean they have no vulnerabilities or that their controls are well-suited to the specific services they will provide. The assessment process needs to probe the specifics, not just confirm the existence of a certificate.

Contractual controls

The contractual relationship with suppliers is the primary mechanism for establishing and enforcing security requirements. Under the GDPR and UK GDPR, a Data Processing Agreement is mandatory for processors handling personal data. Equivalent contractual requirements apply under the New Zealand Privacy Act and the Australian Privacy Act.

Beyond data protection, contracts should establish clear obligations on incident notification timeframes, audit rights, subcontracting controls, exit and termination provisions, and ongoing security standards. The contract needs to anticipate that the relationship will eventually end, and provide for orderly exit including the return or destruction of data.

Ongoing monitoring

Due diligence at onboarding is the starting point, not the end point. Suppliers change. Their security posture can deteriorate. Key personnel leave. They are themselves subject to incidents. Ongoing monitoring of supplier security is necessary to maintain an adequate picture of the risk.

Monitoring approaches include an annual security questionnaire or reassessment for higher-risk suppliers, review of supplier certifications to confirm they remain current, monitoring of public reporting on significant security incidents at suppliers, contractual requirements for suppliers to notify the organisation of significant security changes, and where relevant, independent audits of supplier security controls.

The supplier register needs to be maintained. Most organisations have a clearer picture of their major technology vendors than of the long tail of smaller suppliers who also have data access. A comprehensive, current register of all suppliers with access to the organisation's data or systems is the foundation of supply chain risk management.

The information security programme

Running an effective information security programme is an ongoing management discipline, not a project. It requires clear ownership, adequate resources, regular measurement, and executive engagement. The organisations that get this right are not necessarily the ones with the largest security budgets. They are the ones where security is treated as an operational priority rather than a compliance formality.

The security function

The Chief Information Security Officer or equivalent holds the primary accountability for the information security programme. The role needs to combine technical credibility with governance and communication skills. The CISO who can only talk to technologists is not effective. The CISO who can brief the board on material risks in plain language, engage with regulators constructively, and influence business decision-making before systems are built is.

The size and structure of the security function depend on the organisation's size, sector, and risk profile. A large bank needs a substantial security team with specialist expertise in areas including threat intelligence, security operations, application security, and identity management. A smaller regulated organisation may achieve equivalent outcomes through a smaller team supplemented by managed security services. The key is not the size of the team but whether the function can perform its core roles: risk assessment, control design, monitoring, incident response, and assurance.

Managed security services, including managed Security Operations Centres, outsourced vulnerability management, and cloud-based threat detection, are increasingly viable for organisations that cannot build the full capability internally. They need to be managed like any other supplier, with clear service standards, regular performance review, and contractual protections around data access and incident notification.

Metrics and reporting

A security programme that cannot be measured cannot be managed or improved. The right metrics give management and the board an honest picture of the security posture and highlight where attention is needed.

Useful security metrics cover the number and severity of vulnerabilities identified and the time to remediate them, the volume and outcome of security incidents, penetration test findings and the status of remediation, phishing simulation click rates and trends over time, training completion rates, access review completion and the number of inappropriate accesses identified, and the status of open risk treatment actions.

These metrics need to be presented honestly. Security reporting in large organisations tends to present everything as under control. The board and executive team need accurate information, including where the programme has gaps and what the plan is to address them. The CISO who reports only green is not providing the oversight that the board needs.

For DORA-regulated entities, reporting to competent authorities on ICT-related incidents is a formal regulatory obligation with specific content and timing requirements. The incident classification and reporting process needs to be embedded in the incident management procedure rather than treated as a separate exercise.

Building a security culture

Technical controls and governance frameworks matter. Culture matters more. An organisation where staff understand why security matters, where reporting potential incidents is encouraged rather than penalised, and where security is seen as everyone's responsibility will consistently outperform one where security is treated as IT's problem.

Building that culture is a leadership responsibility. It starts with visible commitment from the board and executive team: not performative statements about the importance of security, but concrete behaviour. Leaders who follow the same security policies they apply to everyone else. Leaders who treat security incidents as learning opportunities rather than failures to be managed. Leaders who invest in the security programme when it needs resources rather than treating it as overhead to be minimised.

The security team's role in culture is to make compliance as easy as possible. Security controls that create unnecessary friction will be worked around. Training that is irrelevant or patronising will be ignored. A security team that engages with the business, understands operational context, and designs controls that work for real people in real workflows is more effective than one that issues mandates without engagement.

New Zealand's Cyber Security Strategy 2026 to 2030 puts real weight on awareness and whole-of-society resilience for regulated organisations, which aligns with where supervisors are already heading. There is less patience for paper controls and greater expectations for working capability. DORA makes the same point directly by requiring security awareness training at all levels, including senior management.

Implementation checklist

For organisations building or strengthening their information security programme, the following sequence provides a practical starting point.

Conclusion

Information security is one of the most demanding disciplines in a regulated organisation because it spans technology, people, process, and governance simultaneously. Getting any one of those right without the others is not enough.

The organisations that manage it well share consistent characteristics. Leadership takes genuine ownership of security risk rather than delegating it to IT. The security function has the authority and access to influence decisions before systems are built and processes are designed. Controls are proportionate to actual risk rather than applied uniformly regardless of context. Incidents are treated as learning opportunities rather than failures to be concealed. The supply chain is managed with the same rigour applied to internal operations.

The regulatory environment is tightening. DORA sets a demanding operational resilience baseline for in-scope EU financial entities. In New Zealand, the Government's Cyber Security Strategy 2026 to 2030 signals a continued move towards stronger, more joined-up national expectations, particularly for critical services. ISO/IEC 27001:2022 has raised the bar on cloud security, threat intelligence, supply chain management, and data leakage prevention. Across jurisdictions, the direction is consistent: away from checkbox compliance and towards demonstrated operational resilience.

The practical response is not to treat each regulatory development as a separate compliance project. It is to build an information security programme that is genuinely risk-based, well-governed, and operationally embedded. An organisation that does this will generally find that it meets its regulatory obligations as a by-product of doing security well, rather than treating compliance as the primary objective and security as secondary.