Information Security Policy

An information security policy establishes the governance framework, accountabilities, and principles that guide how an organisation protects its information assets. The policy defines security roles and responsibilities, articulates the risk management approach, and sets expectations for compliance and audit. Technical security requirements appear in separate standards documents; this policy provides the governance foundation those standards implement.

Information asset

Any data, system, or resource that holds value to the organisation, including documents, databases, applications, infrastructure, intellectual property, and the knowledge held by personnel.

Security control

A safeguard or countermeasure that reduces security risk through prevention, detection, or response mechanisms.

Risk owner

The individual accountable for decisions regarding a specific risk, including acceptance of residual risk after controls are applied.

Security incident

An event that compromises or threatens the confidentiality, integrity, or availability of information assets.

Third party

Any external entity that accesses, processes, stores, or transmits organisational information, including vendors, partners, contractors, and service providers.

Policy scope

The information security policy applies to all information assets regardless of format, location, or ownership model. Digital records stored in cloud systems, paper documents in filing cabinets, and verbal discussions of sensitive matters all fall within scope. The policy binds all individuals who access organisational information: employees, contractors, volunteers, board members, and third parties with authorised access.

Geographic boundaries do not limit policy applicability. Field offices in remote locations operate under identical security obligations to headquarters. Staff travelling internationally carry these obligations with them. Cloud services processing organisational data must meet policy requirements regardless of where their infrastructure physically resides.

The policy establishes minimum requirements. Individual programmes, grants, or operational contexts may impose additional requirements that exceed this baseline. Where external requirements conflict with this policy, the more restrictive requirement applies unless specific exception approval is documented.

Security governance

Security governance establishes the structures, processes, and accountabilities through which the organisation directs and controls its security activities. Effective governance ensures that security decisions align with organisational strategy, resources flow to priority risks, and accountability exists at appropriate levels.

Governance structure

The board of trustees holds ultimate accountability for information security as part of its overall governance responsibility. The board receives security reports at minimum annually and approves the information security policy. Significant security incidents and material changes to the risk profile require board notification within 72 hours.

Executive leadership translates board-level accountability into operational reality. The executive director or chief executive bears responsibility for ensuring adequate security resources, establishing security as an organisational priority, and fostering a culture where security considerations inform decision-making. In organisations with a dedicated chief information security officer, that role reports to executive leadership with direct board access for significant matters.

A security steering committee provides cross-functional oversight of security activities. Membership includes senior representatives from IT, operations, programmes, finance, and human resources. The committee meets quarterly to review security performance, assess emerging risks, approve security investments above delegated thresholds, and resolve conflicts between security requirements and operational needs.

+------------------------------------------------------------------+
|                      BOARD OF TRUSTEES                           |
|            Ultimate accountability, policy approval              |
+----------------------------------+-------------------------------+
                                   |
                                   v
+------------------------------------------------------------------+
|                    EXECUTIVE LEADERSHIP                          |
|         Resource allocation, strategic direction                 |
+----------------------------------+-------------------------------+
                                   |
                                   v
+------------------------------------------------------------------+
|                SECURITY STEERING COMMITTEE                       |
|     Cross-functional oversight, investment decisions             |
|                                                                  |
|  +----------+  +----------+  +----------+  +----------+          |
|  |    IT    |  |Programme |  | Finance  |  |    HR    |          |
|  +----------+  +----------+  +----------+  +----------+          |
+----------------------------------+-------------------------------+
                                   |
                                   v
+------------------------------------------------------------------+
|                    OPERATIONAL SECURITY                          |
|                                                                  |
|  +--------------------+              +--------------------+      |
|  | Security function  |              | IT operations      |      |
|  | (policy, risk,     |<------------>| (implementation,   |      |
|  |  compliance)       |              |  monitoring)       |      |
|  +--------------------+              +--------------------+      |
|                                                                  |
+------------------------------------------------------------------+

Figure 1: Security governance hierarchy showing accountability flow

Governance in smaller organisations

Organisations without dedicated security staff adapt this governance structure to their reality. The IT lead or manager assumes security coordination responsibilities alongside other duties. A single individual combining IT management, security coordination, and operational responsibilities represents common practice in organisations with fewer than 50 staff.

Governance committee functions consolidate into existing management meetings rather than creating separate forums. The senior management team adds security to its standing agenda, reviewing incidents monthly and risk assessments quarterly. Board reporting occurs through existing channels, with security incorporated into operational or risk reports rather than presented separately.

The governance principles remain constant regardless of organisational size: clear accountability exists for security decisions, leadership receives regular security information, and mechanisms exist for escalating significant issues. Implementation scales to match available resources.

Roles and responsibilities

Security responsibilities distribute across the organisation rather than residing solely with technical staff. Every individual who accesses information assets holds security responsibilities appropriate to their role. Clear definition of these responsibilities prevents gaps where no one owns a security obligation and overlaps where multiple parties assume others are acting.

Security function responsibilities

The security function, whether a dedicated team or responsibilities held by IT staff, maintains the security programme and provides specialist expertise. Core responsibilities include developing and maintaining security policies and standards, conducting risk assessments, managing security awareness programmes, monitoring security controls, investigating incidents, and advising on security aspects of projects and initiatives.

The security function does not implement all controls directly. Infrastructure teams implement network security controls. Application teams build security into software. Human resources manages background checks. The security function provides requirements, guidance, and verification while implementation responsibility rests with operational teams.

Management responsibilities

Managers at all levels bear responsibility for security within their areas of authority. This encompasses ensuring staff complete required security training, enforcing policy compliance, identifying and reporting security risks, supporting incident investigation, and incorporating security considerations into operational decisions.

Budget holders make risk-informed decisions about security investments within their areas. A programme manager deciding whether to implement additional data protection measures for a sensitive project exercises security responsibility. The security function advises; the manager decides and accepts residual risk.

Individual responsibilities

Every authorised user holds baseline security responsibilities regardless of role. These include completing assigned security training, protecting credentials and access tokens, reporting suspected incidents and vulnerabilities, following security policies and procedures, and handling information according to its classification.

Individuals cannot delegate or disclaim these responsibilities. A staff member who shares their password violates policy regardless of the seniority or trustworthiness of the recipient. Ignorance of policy provisions does not excuse non-compliance following the onboarding period during which training occurs.

Risk management

Security risk management provides the framework for identifying, assessing, and treating risks to information assets. The organisation cannot eliminate all security risk; risk management ensures that residual risk aligns with organisational risk appetite and that risk-informed decisions allocate security resources effectively.

Risk appetite

The board establishes organisational risk appetite through policy approval and explicit risk appetite statements. Risk appetite varies by consequence type: the organisation accepts higher risk of service disruption than risk of beneficiary data exposure. Programme activities in high-risk contexts operate within different risk parameters than headquarters administrative functions.

Risk appetite translates into practical thresholds guiding operational decisions. Residual risk rated as high or above requires documented acceptance by executive leadership. Critical risk requires board awareness. Risk reduction measures costing over £25,000 require steering committee approval. These thresholds ensure appropriate oversight without paralysing routine security decisions.

Risk assessment

Risk assessments identify threats to information assets, evaluate vulnerabilities those threats could exploit, and estimate the likelihood and impact of successful attacks. Assessments occur at multiple levels: organisation-wide strategic assessments annually, system-level assessments when significant changes occur, and project-level assessments for new initiatives involving information assets.

The assessment methodology combines qualitative and quantitative elements. Likelihood estimates use a five-level scale from rare (less than 1% annual probability) to almost certain (greater than 90% annual probability). Impact assessment considers financial loss, operational disruption, reputational damage, regulatory consequences, and harm to individuals. Combined likelihood and impact determine overall risk rating.

+-------------------------------------------------------------------+
|                    RISK ASSESSMENT MATRIX                         |
+-------------------------------------------------------------------+
|                |                    IMPACT                        |
|   LIKELIHOOD   +----------+----------+----------+----------+------+
|                |Negligible|  Minor   | Moderate |  Major   |Severe|
+----------------+----------+----------+----------+----------+------+
| Almost certain |  Medium  |   High   |   High   | Critical |Crit. |
| Likely         |   Low    |  Medium  |   High   |   High   |Crit. |
| Possible       |   Low    |  Medium  |  Medium  |   High   |High  |
| Unlikely       |   Low    |   Low    |  Medium  |  Medium  |High  |
| Rare           |   Low    |   Low    |   Low    |  Medium  |Medium|
+----------------+----------+----------+----------+----------+------+

Figure 2: Risk rating matrix combining likelihood and impact assessments

Risk treatment

Four treatment options address identified risks. Risk reduction implements controls that lower likelihood or impact. Risk transfer shifts consequences to another party, typically through insurance or contractual arrangements. Risk avoidance eliminates the activity creating the risk. Risk acceptance acknowledges residual risk and proceeds without additional controls.

Treatment selection considers cost-effectiveness, operational impact, and alignment with risk appetite. A £50,000 control addressing a £10,000 annual expected loss lacks justification on financial grounds alone, though non-financial impacts may warrant the investment. Controls must be proportionate to the risk addressed.

Risk owners approve treatment decisions for risks within their authority. The security function recommends treatments and implements approved controls. Accepted risks receive documented justification and scheduled review. The risk register maintained by the security function tracks all identified risks, their treatments, and residual risk levels.

Asset classification

Information assets receive classification based on the harm that unauthorised disclosure, modification, or loss would cause. Classification drives protection requirements: higher classification demands stronger controls. A consistent classification scheme enables personnel to apply appropriate protections without requiring case-by-case security guidance.

Classification levels

The organisation employs four classification levels. Public information is approved for unrestricted distribution and requires no confidentiality protection, though integrity and availability controls may still apply. Internal information is intended for organisational use and should not be shared externally without authorisation, but unauthorised disclosure would cause limited harm. Confidential information could cause significant harm if disclosed and requires active protection measures. Restricted information could cause severe harm to individuals or the organisation and demands the strongest available protections.

Most organisational information falls into the internal category. Confidential classification applies to personal data beyond basic contact information, financial details, security configurations, strategic plans, and information received under confidentiality agreements. Restricted classification reserves for data where disclosure could endanger individuals, such as protection case files, witness identities, or sensitive beneficiary information in hostile contexts.

Classification responsibilities

Information owners assign classification when information assets are created. The owner is the individual or function with accountability for the information, not necessarily its creator. Programme managers own programme data. Finance owns financial records. Human resources owns personnel files.

Classification persists throughout the information lifecycle unless explicitly reclassified. Aggregation may elevate classification; individually internal items may become confidential when combined. Time may reduce classification; embargoed information may become public after release. Reclassification requires owner approval and updates to markings and protections.

Recipients of classified information bear responsibility for maintaining appropriate protections. A staff member receiving confidential information by email must not forward it to personal accounts, print it and leave copies unattended, or discuss its contents in public spaces. Classification travels with information regardless of format changes.

Incident management

Security incidents require prompt detection, effective response, and thorough follow-up. The organisation maintains incident management capabilities proportionate to its risk profile. Every individual bears responsibility for reporting suspected incidents; the security function coordinates response.

Reporting obligations

All personnel must report suspected security incidents immediately upon discovery. Immediate means within one hour during working hours or at the start of the next working day for discoveries outside working hours. Reporting channels include direct contact with the security function, IT service desk escalation, and anonymous reporting mechanisms where personal safety concerns exist.

Reports should include available facts: what was observed, when it was discovered, which systems or data may be affected, and any actions already taken. Reporters need not determine whether an incident has actually occurred; that assessment belongs to the security function. The threshold for reporting is suspicion, not certainty.

Failure to report known or suspected incidents constitutes a policy violation. Good-faith reports never result in adverse consequences for the reporter, even if investigation determines no incident occurred. The organisation prohibits retaliation against incident reporters.

Response obligations

The security function leads incident response with support from IT operations, affected business areas, and specialist resources as required. Response activities follow documented playbooks addressing common incident types. The security function maintains playbooks for ransomware, account compromise, data breach, and malware containment scenarios at minimum.

Incident severity determines response intensity and escalation requirements. Critical incidents, those threatening significant data exposure, major service disruption, or regulatory breach, require executive notification within two hours and board notification within 24 hours. Response teams have authority to take containment actions including system isolation, access suspension, and service interruption without prior approval when delay would increase harm.

Post-incident review follows all significant incidents. Reviews identify root causes, evaluate response effectiveness, and generate improvement actions. Lessons learned inform control enhancements, playbook updates, and training adjustments. The security function tracks improvement actions to completion.

Third-party security

Third parties that access, process, store, or transmit organisational information extend the security perimeter beyond direct organisational control. Third-party security requirements ensure that external relationships do not create unacceptable risk. Requirements scale with the sensitivity of information involved and criticality of services provided.

Due diligence

Security due diligence occurs before engaging third parties with access to confidential or restricted information or provision of critical services. Due diligence assesses the third party’s security posture, relevant certifications, incident history, and contractual willingness to accept security obligations.

Assessment depth matches risk level. A cloud provider hosting restricted beneficiary data undergoes comprehensive assessment including security questionnaire review, certification verification, and potentially on-site audit. A supplier providing office stationery requires no security assessment. The security function provides assessment templates and conducts or supports assessments for high-risk engagements.

Contractual requirements

Contracts with third parties accessing organisational information include security provisions appropriate to the engagement. Standard provisions address data handling obligations, incident notification requirements, audit rights, and termination data return or destruction. Contracts for confidential or restricted data access include specific protection requirements, breach liability, and security certification maintenance obligations.

The security function maintains template contract clauses for common engagement types. Legal review incorporates these clauses into vendor agreements. Deviations from standard security requirements require security function approval and documented risk acceptance.

Ongoing management

Third-party security extends beyond initial assessment. Critical vendors undergo annual security review including certification status verification and incident enquiry. Material changes to vendor services or security posture trigger reassessment. The organisation monitors vendor security disclosures and responds to reported vulnerabilities affecting products in use.

Third-party security incidents affecting organisational data require notification within 24 hours under standard contract terms. The organisation’s incident response procedures activate for third-party incidents as for internal incidents. Contract provisions ensure cooperation with investigation and remediation activities.

Compliance and audit

The organisation demonstrates security policy compliance through ongoing monitoring, periodic assessment, and independent audit. Compliance activities provide assurance to leadership, donors, regulators, and partners that security commitments translate into operational reality.

Internal compliance

The security function monitors compliance with security policies and standards through technical controls, process reviews, and testing activities. Continuous monitoring employs automated tools where feasible: vulnerability scanners identify unpatched systems, configuration management tools detect drift from security baselines, and access reviews verify permission appropriateness.

Periodic compliance assessments evaluate control effectiveness beyond what continuous monitoring captures. Assessments test controls through examination, interview, and testing. The security function conducts quarterly assessments of high-priority controls and annual comprehensive assessments covering all policy areas.

Identified non-compliance generates remediation requirements tracked to completion. Significant non-compliance escalates to the security steering committee. Persistent non-compliance affecting critical controls escalates to executive leadership with recommendations for enforcement action.

External audit

Independent security audits occur at minimum annually. External auditors assess policy implementation, control effectiveness, and compliance with applicable regulations and standards. Audit scope encompasses areas of highest risk and rotates to cover all significant security domains over a three-year cycle.

Donor and regulatory requirements may mandate specific audit activities. Grant agreements specifying security requirements include audit provisions. Regulatory frameworks such as GDPR establish supervisory authority audit rights. The organisation maintains audit readiness through documentation, evidence preservation, and designated audit liaison personnel.

Audit findings receive management responses and remediation timelines. The security steering committee reviews external audit reports and monitors remediation progress. Significant findings appear in board reporting. The organisation does not suppress or minimise unfavourable audit findings; transparent response to identified weaknesses strengthens security over time.

Certification and attestation

The organisation pursues security certifications appropriate to its context and stakeholder requirements. Certification decisions balance the assurance value and stakeholder expectations against certification cost and maintenance burden. Common certifications for mission-driven organisations include Cyber Essentials, Cyber Essentials Plus, ISO 27001, and SOC 2.

Certification maintenance requires ongoing compliance, not point-in-time achievement. The security function integrates certification requirements into standard operations and maintains evidence supporting certification claims. Recertification assessments occur according to certification body schedules.

Policy maintenance

The information security policy requires regular review to maintain alignment with organisational needs, threat landscape changes, regulatory developments, and security best practices. Stale policies create compliance fiction where documented requirements diverge from operational reality.

Review cycle

Full policy review occurs annually. The review examines whether policy provisions remain appropriate, identifies gaps created by organisational or environmental changes, and incorporates lessons from incidents and audits. The security steering committee approves substantive changes; the board ratifies material revisions.

Interim updates address urgent issues between annual reviews. Regulatory changes, significant incidents, or material organisational changes may necessitate policy amendments outside the normal cycle. The security function proposes interim updates with justification; approval follows standard change governance.

Version control

Policy versions receive clear identification through version numbering and effective dates. The current approved version remains accessible to all personnel through the organisational intranet or document management system. Previous versions are archived for reference but clearly marked as superseded.

Significant changes trigger communication and training updates. Personnel receive notification of material policy changes with explanation of new requirements. Training materials update to reflect current policy provisions. The security function maintains change logs documenting the rationale for policy evolution.

See also

• Access Control Standard
• Cryptography Standard
• Data Protection Policy
• Acceptable Use Policy
• Security Risk Management
• Incident Response Framework
• Third-Party Security Risk