Information Security Handbook

Introduction and How to Use This Handbook

Security is not a product you buy or a department you call. It is a set of habits practised by every person who touches company systems, data, or devices. This handbook describes how we expect everyone at the company to work safely. It collects the controls and behaviours that the industry considers best practice in 2026, expressed in plain language so that they apply to engineers, sales staff, finance, support, and leadership alike.

The threats we face have not stood still. Most successful breaches today do not begin with an exotic technical exploit. They begin with a stolen password, a convincing phishing email, an unmanaged laptop, a forgotten admin account belonging to someone who left months ago, or a database backup that was never tested. Each of these is preventable, and prevention is largely a matter of discipline rather than budget.

How the handbook is organised

The first sections cover controls that affect everyone: passwords, multi-factor authentication, devices, identity, network and Wi-Fi use, email, and data handling. Later sections cover the employee lifecycle (onboarding and offboarding), engineering practice (secure development, databases, backups, disaster recovery), and the governance layer (compliance, incident response, vendor risk). The final section is a set of quick-reference checklists you can use day to day.

The shared-responsibility mindset

Think of security as a chain. The organisation provides tooling, policy, and monitoring, but a single weak link - one reused password, one device without encryption, one click on a malicious link - can compromise the whole. Your job is to be a strong link and to raise your hand the moment something looks wrong. Reporting a mistake quickly is always better than hiding it. We treat honest reports as a positive, never as grounds for blame.

• Assume breach. Design your habits as if an attacker is already inside the network. Verify, segment, and limit what any single credential can reach.
• Least privilege. Hold only the access you need to do your job, and only for as long as you need it.
• Defence in depth. No single control is perfect; we layer several so that the failure of one does not become a breach.
• Report fast. The cost of an incident grows by the hour. Early reporting is the single most valuable thing you can do.

The Ten Golden Rules

If you remember nothing else from this handbook, remember these. Each is expanded in a later section, but these ten habits prevent the large majority of real-world incidents.

1. Use a unique, long passphrase for every account - stored in the company password manager, never reused.
2. Turn on MFA everywhere, and prefer passkeys. Never approve a prompt you did not start.
3. Think before you click. Verify any unexpected request for money, credentials, or data through a second, known channel.
4. Lock your screen whenever you step away, and keep devices physically secure.
5. Keep devices updated. Install patches and restart promptly - it closes the doors attackers use.
6. Keep company data in approved systems only. No personal email, drives, or unsanctioned apps.
7. Never share secrets - passwords, keys, customer data - in chat, email, code, or public AI tools.
8. Hold only the access you need, and speak up if you have more than your job requires.
9. On untrusted networks, use the VPN before touching company resources.
10. Report anything suspicious immediately. Fast reporting is the single most valuable thing you can do - and you will never be blamed for it.

The Threat Landscape in 2026

Understanding what we are defending against makes the rest of this handbook make sense. The controls described here map directly to the attacks that are actually causing harm today. The picture in 2026 is shaped by automation, artificial intelligence, and the fact that identity - not the network perimeter - is now the main battleground.

The threats that matter most

Passwords and Credentials

Passwords remain the most common way accounts are compromised, almost always because they are weak, reused, or phished. Modern guidance from NIST (SP 800-63B) and the major platform vendors has shifted away from short, complex, frequently-rotated passwords toward long passphrases protected by a password manager and a second factor.

What makes a strong password in 2026

• Length beats complexity. A passphrase of 4-5 random words (for example, correct-harbour-violin-stamp) is both stronger and easier to remember than P@ssw0rd1. Aim for at least 14 characters; 16 or more for privileged accounts.
• Uniqueness is non-negotiable. Every account gets its own password. The single biggest cause of account takeover is credential reuse across sites - one leaked service exposes all the others.
• No predictable patterns. Avoid names, dates, the company name, keyboard walks (qwerty), or a base word with an incrementing number.
• Screen against known-breached passwords. Our systems check new passwords against breach corpora (for example Have I Been Pwned). If a password is rejected for this reason, it has appeared in a public breach and must not be used anywhere.

Use the company password manager

Every employee is issued a password manager. It generates long random passwords, stores them encrypted, fills them only on the correct domain (which itself defends against phishing), and lets you share credentials with colleagues without sending them over chat or email.

Password rotation: the modern position

For years the rule was to change every password every 90 days. Current best practice, reflected in NIST guidance, is to stop forcing routine time-based rotation of user passwords, because it pushes people toward weak, predictable variations (Spring2026!, Summer2026!) and offers little protection. Instead, rotate on evidence of risk.

Privileged and shared accounts

Administrative accounts are the keys to the kingdom and attract the most attention from attackers. Treat them with extra care:

• Use a separate, dedicated admin account - never your day-to-day account - for privileged tasks, and never use it to browse the web or read email.
• Wherever possible, privileged credentials are vaulted in a Privileged Access Management (PAM) tool that checks them out for a single session and rotates them afterwards.
• Shared logins are discouraged. When a system genuinely cannot support individual accounts, document who has access, protect the credential in the password manager, and rotate it whenever a holder leaves.

Multi-Factor Authentication and Passkeys

A password alone is no longer sufficient. Multi-factor authentication (MFA) requires a second proof of identity, so that a stolen password by itself cannot unlock an account. MFA is mandatory for all company accounts and for any third-party service holding company data.

Not all factors are equal

Resisting MFA attacks

• Never approve a prompt you did not initiate. Attackers spam push notifications hoping you will tap 'approve' out of habit or fatigue. If you get an unexpected prompt, deny it and report it - your password may be compromised.
• Beware of help-desk impersonation. Attackers call pretending to be IT and ask you to read a code or approve a prompt. We will never ask you to do this. Verify through a known channel.
• Register backups. Enrol at least two factors (for example a security key plus an authenticator app) so a lost phone does not lock you out.

Devices, Intune and Mobile Device Management

Company data is only as safe as the device it sits on. Every device that accesses company resources - laptop, desktop, phone, or tablet - must be known to us and must meet a minimum security bar before it is allowed in. We use Microsoft Intune (with Entra ID) as our unified endpoint management and Mobile Device Management (MDM) platform.

Enrollment and compliance

When you receive a company device it is enrolled in Intune, which applies our security baseline automatically. Intune continuously checks each device against a compliance policy; non-compliant devices are blocked from company data by Conditional Access until they are brought back into line.

• Disk encryption is enforced (BitLocker on Windows, FileVault on macOS) so a lost or stolen device does not leak data.
• Screen lock with a strong PIN or biometric and a short auto-lock timeout (no more than a few minutes).
• Up-to-date OS and patches. Devices below the minimum patch level lose access until updated.
• Endpoint protection / EDR running and reporting.
• Secure boot and firewall enabled; local admin rights restricted.

Application management

Intune also manages the software on your device. Approved applications are delivered through the company portal; this keeps software licensed, patched, and free of tampered installers from the open internet.

• Install business software from the company portal, not from random download sites.
• Do not install unapproved or 'cracked' software; it is a common malware vector and a licensing risk.
• Mobile app data is containerised so company information can be wiped without touching your personal data.

Bring Your Own Device (BYOD)

Where personal devices are permitted for work, we use app-level protection (Mobile Application Management) rather than taking full control of your device. Company data lives in a protected container we can selectively wipe; your personal photos and apps are untouched and out of our view.

Vulnerability and Patch Management

Most breaches exploit a weakness that was already known and for which a fix already existed. Closing that gap quickly - patching - is one of the highest-value, lowest-glamour activities in security. It applies to operating systems, applications, firmware, network gear, containers, and the libraries inside our own software.

Keep everything current

• Enable automatic updates on your devices and do not defer them indefinitely. A pending restart is not optional - it is often what applies a security fix.
• Servers and infrastructure are patched on a defined cadence, with critical fixes fast-tracked outside the normal window.
• End-of-life software that no longer receives security updates is retired or isolated; running it is a standing risk.

Risk-based prioritisation

Not every vulnerability is equally urgent. We prioritise using severity (CVSS), whether the flaw is being actively exploited in the wild (for example, presence on the CISA Known Exploited Vulnerabilities list), and how exposed and important the affected system is.

Identity, Directory and Domain Security

Identity is the new perimeter. With staff working from many locations and devices, the directory (Entra ID / Active Directory) is what decides who can reach what. Getting identity right prevents the lateral movement that turns a single compromised account into a company-wide breach.

Core identity principles

• Single identity, centrally managed. One account per person, provisioned from HR records, so access can be granted and revoked in one place.
• Role-based access control (RBAC). Permissions are attached to roles and groups, not handed out individually, so access is consistent and auditable.
• Least privilege and just-in-time. Standing admin rights are minimised. Privileged roles are elevated only when needed, for a limited time, with approval (Privileged Identity Management).
• Separation of duties. Sensitive actions require more than one person, so no single account can both make and approve a critical change.

Hardening the directory

• Enforce MFA and Conditional Access for every account, with stricter rules for administrators.
• Use separate, cloud-only or dedicated admin accounts; never browse the web or read mail from an account with directory-admin rights.
• Disable legacy authentication protocols that cannot enforce MFA.
• Monitor for risky sign-ins (impossible travel, unfamiliar locations, leaked-credential matches) and respond automatically.
• Regularly review group membership and privileged-role assignments; remove what is no longer needed (access recertification).

Group Policy and configuration baselines

On-premises and hybrid environments use Group Policy (and Intune configuration profiles in the cloud) to enforce a consistent secure baseline: password and lockout policy, restricted local admin, disabled obsolete features, audit logging, and approved configurations aligned to a recognised benchmark such as CIS or the Microsoft security baselines.

Network and Wi-Fi Security

Networks should be designed so that getting onto one network does not mean getting onto everything. We segment networks, secure wireless access, and increasingly rely on identity-based access rather than network location.

Wi-Fi

• Corporate Wi-Fi uses WPA3 (or WPA2-Enterprise at minimum) with 802.1X authentication tied to your identity or device certificate - not a shared password.
• Guest Wi-Fi is fully isolated from corporate systems and is the only network visitors and personal devices should use.
• Never bridge networks - do not connect a company device to corporate Wi-Fi and a personal hotspot at the same time, and do not plug rogue access points or routers into the corporate network.

Segmentation and Zero Trust

We divide the network into zones - user devices, servers, databases, management, guest, and operational technology - separated by firewalls so traffic between zones is controlled and logged. The direction of travel is Zero Trust: rather than trusting anything inside the perimeter, every request is authenticated, authorised, and encrypted based on identity and device health, regardless of where it originates.

• Production systems and databases live in protected segments reachable only through controlled paths (bastion hosts, just-in-time access).
• Remote access is via VPN or a Zero Trust Network Access (ZTNA) broker, always with MFA.
• Inbound exposure to the internet is minimised; what must be exposed sits behind a WAF and is monitored.
• Default-deny firewall rules: only explicitly required traffic is permitted.

Everyday network hygiene

• Keep home routers patched, change default admin passwords, and use WPA3/WPA2 with a strong passphrase.
• Do not connect unknown USB drives or devices to company equipment.
• Report any unexpected device, cable, or access point you find plugged into the network.

Cloud and SaaS Security

Most of our systems and data now live in the cloud and in software-as-a-service (SaaS) applications. The cloud is not automatically more or less secure than a server room - but it shifts where the risks are. The single biggest cause of cloud breaches is misconfiguration, not provider failure.

The shared-responsibility model

Cloud providers secure the underlying infrastructure; we remain responsible for how we configure and use it - identities, access policies, network rules, and above all our data. Assuming the provider 'has it covered' is a common and dangerous mistake.

• Identity is the control plane. Apply MFA, least privilege, and just-in-time elevation to cloud consoles exactly as for any admin access. Cloud root/owner accounts are crown jewels - protect them with the strongest controls and use them almost never.
• No public-by-accident. Storage buckets, databases, and management interfaces must not be exposed to the internet unless deliberately and necessarily so. Misconfigured public storage is a recurring source of large data leaks.
• Encrypt and manage keys for data at rest and in transit; keep key management separate from the data.
• Use posture management. Automated tools (CSPM) continuously check cloud configuration against benchmarks and flag drift before it becomes an incident.
• Tag and track resources so nothing is forgotten; orphaned cloud resources are unmonitored and unpatched.

SaaS governance

Every SaaS app that touches company data is part of our attack surface. They are approved, configured securely, and connected to our identity provider for single sign-on (SSO) so access is centrally controlled and removed at offboarding.

• Use SSO and central provisioning rather than standalone logins, so access ends when employment does.
• Review third-party app permissions and OAuth grants - a malicious or over-permissioned app integration can read your mailbox or files.
• Configure each SaaS tenant's security settings (sharing limits, MFA enforcement, audit logging) rather than accepting insecure defaults.

Email, Phishing and Social Engineering

Email and messaging remain the number-one entry point for attackers. Phishing has grown more convincing, and generative AI now produces flawless, well-targeted messages - and even deepfake voice and video. Technical filters catch most attacks, but the last line of defence is a trained, sceptical human.

Spotting a phishing attempt

• Urgency and pressure - 'act now or your account will be closed', 'the CEO needs this transfer immediately'.
• Unexpected requests for credentials, payments, gift cards, or changes to bank details.
• Mismatched or look-alike senders and links - hover before you click; check the real domain.
• Unusual attachments, especially documents asking you to 'enable macros' or files with double extensions.
• Requests to break process - bypassing approval, keeping something secret, or moving the conversation off official channels.

Business Email Compromise (BEC)

BEC attacks impersonate executives, suppliers, or colleagues to redirect payments or extract data. They often involve no malware at all, which is why they slip past technical filters. The defence is process: dual authorisation for payments, mandatory verification of any change to supplier bank details, and a culture where it is always acceptable to slow down and check.

If you clicked

Mistakes happen. If you clicked a link, opened an attachment, or entered credentials on a suspicious site, report it to IT/security immediately and change any password you may have exposed. Speed matters far more than blame.

Data Classification and Handling

Not all data carries the same risk. Classifying data lets us apply the right level of protection without slowing down low-risk work. Everyone is responsible for handling data according to its classification.

Classification levels

Handling rules

• Encrypt confidential data in transit (TLS) and at rest. Devices are already encrypted; do not move data onto unencrypted media.
• Store data in approved systems - sanctioned cloud storage, not personal drives, personal email, or unsanctioned 'shadow IT' apps.
• Share by link with least privilege, set expiry where possible, and review who has access periodically.
• Minimise and retain only what you need. Delete data you no longer require, in line with the retention schedule. Less data held means less data at risk.
• Protect personal data in line with GDPR and applicable privacy law - collect only what is necessary, use it only for stated purposes, and respect data-subject rights.

Cryptography, Certificates and Key Management

Encryption protects data when other controls fail - a stolen disk, an intercepted connection, a leaked backup. Used correctly it is extremely strong; the weak points are almost always implementation and key handling, not the mathematics.

Use strong, current standards

• In transit: TLS 1.2 or 1.3 for all connections carrying company data, with weak protocols and ciphers disabled. No unencrypted HTTP, FTP, or telnet for anything sensitive.
• At rest: AES-256 (or equivalent) for disks, databases, and backups.
• Hashing: strong, salted password hashing (for example Argon2 or bcrypt) - never plain text, never fast unsalted hashes like MD5 or SHA-1.
• Use vetted libraries. Never invent your own cryptographic algorithm or protocol; use well-reviewed, maintained implementations.

Certificates

• Track certificates and their expiry; an expired certificate causes outages and erodes trust. Automate renewal where possible.
• Protect private keys as the secrets they are - in a key store or hardware security module (HSM), never in a repository or shared folder.
• Use trusted certificate authorities and enforce certificate validation; do not disable validation 'to make it work'.

Acceptable Use and Everyday Behaviour

Company systems are provided for company work. Sensible personal use is usually tolerated, but everything you do on company systems may be logged and must stay lawful and professional. These behaviours protect both you and the organisation.

Everyday secure habits

• Lock your screen whenever you step away (Windows+L, or Ctrl+Cmd+Q on macOS). An unlocked, unattended machine is an open door.
• Clear desk and clear screen - do not leave confidential documents, notes, or credentials visible.
• Beware of shoulder-surfing in public spaces; use a privacy screen when travelling.
• Keep work and personal separate - separate accounts, separate browsers/profiles, no personal logins on company-critical systems.
• Think before you share on social media; attackers harvest details (roles, travel, org structure) to craft targeted attacks.

Software and AI tools

• Install only approved software, from approved sources. Request new tools through IT rather than installing them quietly.
• Treat AI assistants as untrusted recipients: never feed them secrets, credentials, customer data, or unreleased information unless the tool is company-approved and contractually covered.
• Keep browsers and extensions to a minimum; malicious browser extensions are a growing threat.

Using AI and Generative Tools Safely

Generative AI tools are now part of everyday work, and used well they are a genuine productivity boost. They also introduce new risks: data leakage, over-trust in plausible but wrong output, and new avenues of attack. This section sets the ground rules; specific approved tools and their limits are maintained by IT.

Protect company and personal data

• Use only company-approved AI tools for any work involving company, customer, or personal data. Approved tools are covered by contracts that keep our data out of public training sets.
• Never paste secrets, credentials, source code, customer data, or unreleased information into public AI services. Treat a public chatbot like posting on a public forum.
• Assume anything you submit to an unapproved tool may be stored, processed elsewhere, or exposed.

Trust, but verify

• AI output can be confidently wrong ('hallucinations'). Verify facts, figures, code, and legal or security guidance before relying on them.
• Review and understand AI-generated code before merging it - it can contain vulnerabilities, insecure patterns, or licensing issues. The author remains accountable, not the tool.
• Do not let AI make consequential decisions (hiring, access, payments, security exceptions) without human judgement.

AI Threats and Data Leakage

AI tools create a fast, often invisible route for sensitive data to leave the company - and a powerful new toolkit for attackers. The risk is not theoretical: pasting the wrong text into a chatbot can expose a password, an API key, or a customer's data in seconds, with no malware and no warning. This section focuses on the three things most often leaked, and on attacks that use AI against us.

What gets leaked into AI tools

Why public AI tools are risky for secrets

• Data may be retained or used for training. Unless a tool is contractually bound not to, your input can be stored, reviewed by humans, or absorbed into a model - and later surface in someone else's output.
• You lose control and visibility. Once submitted, the data is on someone else's infrastructure, possibly in another jurisdiction, outside our logging, backups, and deletion processes.
• Leaks are silent. Unlike a phishing click, there is no alert. The exposure is often discovered only later, if at all.
• A leaked secret is a compromised secret. Treat any credential or key exposed to an unapproved tool as breached: rotate it immediately and report it.

AI used as an attack tool

Attackers use the same technology against us. Awareness of these techniques is itself a defence.

• Hyper-realistic phishing and deepfakes. AI writes flawless, personalised lures and clones voices and video. A convincing 'CEO' call or email is not proof of identity - verify out of band.
• Prompt injection. Hidden instructions planted in a document, web page, email, or ticket can hijack an AI assistant that is connected to your data or tools, making it leak information or take unintended actions. Be cautious about pointing AI assistants at untrusted content.
• Data poisoning and malicious models. Downloaded models, plugins, or AI browser extensions can be backdoored. Use only approved AI tools and integrations.
• Faster exploitation. AI helps attackers find and weaponise vulnerabilities quickly - another reason to patch promptly and keep least privilege tight.

Remote and Hybrid Working

Most of us work at least part of the time outside the office. The security bar does not drop when you leave the building - if anything it rises, because home and public environments are less controlled.

• Use company devices for company work; if BYOD is permitted, use the protected work container only.
• Connect through the VPN/ZTNA on any network you do not fully trust.
• Secure your home network: patched router, changed default password, WPA3/WPA2, separate IoT devices onto a guest network.
• Keep work conversations private - others at home, in cafes, or on trains should not see screens or hear confidential calls.
• Physically secure devices: never leave a laptop visible in a car or unattended in a public place.

Onboarding New Joiners Securely

Onboarding sets the security tone and provisions exactly the right access - no more, no less. A clean, role-based onboarding prevents the slow accumulation of excess permissions ('privilege creep') that makes later accounts so dangerous if compromised.

Before day one

• HR triggers identity creation; access is derived from the role, using predefined role-based access profiles rather than 'copy someone else's access'.
• A managed, encrypted, enrolled device is prepared and assigned.
• Accounts are created with MFA enrolment required at first sign-in.

Day one and first week

• The joiner sets up MFA (ideally a passkey) and the password manager, and changes any temporary password.
• Security awareness training is completed early, before broad access is granted.
• The joiner acknowledges this handbook and the acceptable-use policy.
• Access is verified against the role profile: the manager confirms what was granted is appropriate.

Offboarding Leavers Securely

Offboarding is one of the highest-risk moments in the employee lifecycle. Forgotten accounts belonging to former staff are a classic route to a breach, and departing staff occasionally take data with them. A prompt, complete, and checklist-driven offboarding is essential.

At the moment of departure

• Disable accounts promptly - on the effective date, and immediately (ideally before notification) for involuntary departures. Disable rather than delete first, to preserve data and audit trails.
• Revoke access everywhere, including SaaS apps, VPN, remote access, building access, and any third-party systems - not just the primary directory account.
• Reclaim devices and remotely wipe company data from any personal devices.
• Revoke and rotate credentials the leaver knew: shared accounts, service accounts, API keys, and any privileged passwords.
• Revoke certificates, tokens, and SSH keys associated with the person.

Data and access transfer

• Transfer ownership of mailboxes, files, and any systems the person administered to their manager or successor.
• Forward or convert the mailbox per policy; do not simply leave it active and unattended.
• Review what the leaver had access to and confirm nothing was missed (an access report supports this).

Secure Development Practices

Developers build the systems that hold company and customer data, so engineering habits have an outsized effect on security. This section applies to anyone writing code, managing infrastructure, or running pipelines. The goal is to build security in from the start ('shift left') rather than bolt it on later.

Secrets management

• Never hard-code secrets - passwords, API keys, tokens, certificates - in source code, config files, or container images.
• Store secrets in a dedicated secrets manager or vault; inject them at runtime. Prefer short-lived, automatically-rotated credentials and workload identity over long-lived static keys.
• Run automated secret scanning in pre-commit hooks and CI to catch leaks before they merge.
• If a secret is exposed, treat it as compromised: rotate it immediately - removing it from history is not enough.

Code, review and dependencies

• Peer review every change. No code reaches production without review and passing automated checks. Protect main branches and require approvals.
• Validate all input and encode all output to prevent injection (SQL injection, XSS, command injection). Use parameterised queries - never build SQL by string concatenation.
• Manage dependencies actively. Use software composition analysis (SCA) to find vulnerable libraries, pin versions, and patch promptly. Maintain a software bill of materials (SBOM).
• Use static and dynamic analysis (SAST/DAST) in the pipeline to catch flaws automatically.
• Follow the OWASP Top 10 as a baseline for web application risks.

CI/CD and infrastructure as code

• Secure the pipeline itself: it has powerful credentials and is a high-value target. Apply least privilege to build agents and use short-lived deployment credentials.
• Scan infrastructure-as-code (Terraform, etc.) and container images for misconfigurations and vulnerabilities before deployment.
• Sign artifacts and verify provenance to defend against supply-chain tampering.
• Keep environments separated (development, staging, production) with distinct credentials and access controls.

Environment and data separation

• Developers do not hold standing access to production; production access is just-in-time, approved, logged, and time-boxed.
• Log security-relevant events, but never log secrets or sensitive personal data.
• Apply the principle of least privilege to application service accounts - an app should reach only the resources it needs.

Database Security

Databases are where the most valuable data concentrates, which makes them a primary target. Protecting them combines access control, encryption, monitoring, and disciplined operations.

Access control

• Grant least privilege: applications and people get only the specific rights they need, scoped to specific schemas or tables - never blanket admin.
• Use individual or application-specific accounts, not shared logins, so actions are attributable.
• Place databases in protected network segments, never directly exposed to the internet; reach them through bastions or private endpoints.
• Require MFA for human administrative access, ideally brokered through a PAM tool.

Encryption and protection

• Encrypt data at rest (transparent data encryption) and in transit (TLS for all connections).
• Protect or tokenise the most sensitive fields (for example payment data) so that even database access does not reveal them in the clear.
• Manage encryption keys in a dedicated key-management service, separate from the data.

Monitoring and operations

• Enable audit logging of access and privileged actions; review and alert on anomalies (bulk exports, off-hours admin access, failed-login spikes).
• Patch database engines promptly; unpatched databases are repeatedly exploited.
• Harden the configuration against a benchmark (CIS) - remove default accounts, sample databases, and unused features.
• Control and review schema changes through the same reviewed, version-controlled process as application code.

Backups

Backups are the ultimate safety net - against hardware failure, human error, and especially ransomware. Modern ransomware deliberately seeks out and destroys backups before triggering encryption, so backups must be designed to survive an attacker who already has wide access.

The 3-2-1-1-0 rule

Best practices

• Immutability. Use write-once-read-many (WORM) or object-lock storage so backups cannot be encrypted or deleted, even with stolen admin credentials.
• Encryption. Encrypt backups at rest and in transit; they hold the same sensitive data as production.
• Separation. Backup systems should have their own credentials and access path, isolated from the production identity plane, so one compromise does not reach both.
• Coverage. Back up not just databases but configuration, infrastructure-as-code, SaaS data (email, files, code repositories - these are your responsibility, not the vendor's), and documentation.
• Retention. Keep backups long enough to recover from an intrusion that went undetected for weeks, in line with the retention and compliance schedule.

Disaster Recovery and Business Continuity

Disaster recovery (DR) is the plan for restoring IT systems after a major disruption - a ransomware attack, a data-centre or cloud-region outage, a destructive failure, or a natural disaster. Business continuity (BC) is the wider plan for keeping the business operating throughout. Both must be written down, owned, and rehearsed before they are needed.

Setting the targets

Different systems warrant different targets. Classify systems by criticality (a business impact analysis) and set RTO/RPO accordingly - a customer-facing transaction system needs far tighter targets than an internal wiki.

Building resilience

• Maintain redundancy for critical systems: multiple availability zones or regions, replicated data, and the ability to fail over.
• Keep current, version-controlled infrastructure-as-code so environments can be rebuilt from scratch quickly and identically.
• Document recovery runbooks: step-by-step procedures, system dependencies and recovery order, key contacts, and where backups and keys are held.
• Store the DR plan and contacts somewhere reachable even if primary systems and identity are down (an out-of-band copy).

Logging, Monitoring and Detection

You cannot defend against what you cannot see. Comprehensive logging and active monitoring are how we detect attacks early, investigate incidents accurately, and prove what happened afterwards. Detection turns a silent, months-long intrusion into a contained event.

What we log and watch

• Authentication and access events, privileged actions, configuration changes, and security-tool alerts are collected centrally (a SIEM).
• Endpoint detection and response (EDR) watches devices for malicious behaviour and can isolate a compromised machine automatically.
• Logs are time-synchronised, tamper-resistant, and retained long enough to investigate intrusions that surface weeks later.
• Alerts are tuned and triaged so real signals are not lost in noise; high-severity alerts are actioned promptly, day and night.

Protecting the evidence

• Logs must never contain secrets, passwords, or unnecessary personal data - logging sensitive data turns the log into a new liability.
• Access to logs is itself restricted and monitored; attackers try to delete logs to hide their tracks, so we forward them to protected, separate storage.

Incident Response and Reporting

How fast and how calmly we respond to a security incident largely determines its cost. Everyone has one essential role: recognise something is wrong and report it immediately. The specialist response is handled by the security/incident team following a defined plan.

What to report

• A clicked phishing link, opened suspicious attachment, or credentials entered on a doubtful site.
• A lost or stolen device, or a device behaving strangely (unexpected pop-ups, slowness, disabled antivirus).
• An unexpected MFA prompt, password-reset email, or sign-in alert you did not trigger.
• Data sent to the wrong recipient, or any suspected exposure of confidential or personal data.
• Anything that simply feels off - it is always better to report and be wrong than to stay silent.

How incidents are classified

The response team grades each incident by severity, which sets the urgency, who is involved, and how quickly leadership and any regulators are informed.

The response lifecycle

The incident team follows a recognised lifecycle (aligned to NIST and ISO 27035): prepare, detect and analyse, contain, eradicate, recover, and learn. Containment limits the spread; eradication removes the attacker's foothold; recovery restores clean systems; and a blameless post-incident review captures lessons so the same gap is not exploited twice.

Legal and regulatory duties

Some incidents carry legal reporting obligations - for example, a personal-data breach under GDPR must be assessed and, where required, reported to the regulator within 72 hours, and affected individuals may need to be told. Sector rules such as NIS2 and DORA add their own notification timelines. This is precisely why fast internal reporting matters: the clock may already be running.

Privacy and Personal Data Protection

Protecting personal data is both a legal duty (under GDPR and equivalent laws) and a matter of trust with our customers and colleagues. Privacy and security overlap but are not identical: security keeps data safe; privacy governs whether we should hold and use it at all, and how.

Core privacy principles

• Lawful basis and purpose limitation: only collect personal data with a valid reason, and use it only for the purpose stated when it was collected.
• Data minimisation: collect and keep the minimum necessary. Do not hoard personal data 'just in case'.
• Storage limitation: delete personal data when it is no longer needed, following the retention schedule.
• Accuracy: keep personal data correct and up to date.
• Transparency: people have the right to know what data we hold and why, and to exercise rights such as access and erasure.

Handling personal data day to day

• Keep personal data in approved systems with appropriate access controls; never copy it to personal devices, personal email, or unsanctioned tools.
• Apply extra care to special-category data (health, biometric, and similar) and to large datasets - their breach impact is high.
• Use anonymised, masked, or synthetic data for testing and analytics wherever possible.
• When sharing personal data with a third party, ensure a data-processing agreement is in place first.

Compliance and Governance

Compliance frameworks turn good security into demonstrable, auditable practice - and several are legal requirements. They are not box-ticking for its own sake: each control in this handbook maps to obligations our customers, regulators, and partners expect us to meet.

Frameworks that shape how we work

What this means for you

• Follow documented policies and processes - auditors check that we do what we say.
• Keep records: approvals, access reviews, training completion, and change tickets are evidence of compliance.
• Handle personal data lawfully and respect privacy rights; involve the Data Protection Officer when in doubt.
• Complete assigned security and compliance training on time.

Physical Security and Third-Party Risk

Physical security

Digital controls can be undone by a physical lapse - a tailgater in the server room, a stolen laptop, or documents left on a printer.

• Wear and display access badges; do not let people tailgate through secure doors, however polite it feels. Challenge or report unescorted strangers.
• Escort visitors at all times in non-public areas and sign them in.
• Secure sensitive areas (server rooms, comms rooms) to authorised staff only.
• Collect printouts promptly, shred confidential paper, and follow secure disposal for old media and devices (wipe or destroy, never just bin).
• Lock devices and never leave them unattended in public or visible in vehicles.

Third-party and supply-chain risk

Our security is only as strong as the vendors and partners we rely on. Many breaches arrive through a trusted third party, so suppliers who handle our data or connect to our systems are assessed and held to appropriate standards.

• New vendors handling company or personal data go through security and privacy due diligence before approval, and are covered by contracts with security and data-processing terms.
• Vendor access is least-privilege, time-bound, and monitored - and removed when the engagement ends.
• We track the software and services in use (including their sub-processors) and watch for vulnerabilities and breaches affecting them.

Security Awareness and Culture

Technology and policy only work inside a culture that takes security seriously. The strongest organisations make security everyone's business and make it safe to ask questions and admit mistakes.

• Complete security awareness training when you join and on the regular refresh cycle.
• Expect simulated phishing exercises - they are practice, not a trap. If you fall for one, the follow-up training is the point, not punishment.
• Stay curious and sceptical: a moment's pause before clicking, approving, or paying prevents most incidents.
• Share concerns and near-misses; they help everyone learn and improve our defences.

Quick-Reference Checklists

Every-day security checklist

• Lock your screen whenever you step away.
• Use the password manager; one unique strong passphrase per account.
• Use MFA / passkeys; never approve a prompt you did not start.
• Think before you click; verify unexpected requests out of band.
• Keep company data in approved systems only.
• Connect via VPN/ZTNA on untrusted networks.
• Install only approved software from approved sources.
• Report anything suspicious - immediately and without fear of blame.

Manager / onboarding checklist

• Access provisioned from a role profile, not copied from a colleague.
• Managed, encrypted, enrolled device assigned.
• MFA enrolled and temporary password changed at first login.
• Security training completed before broad access is granted.
• Handbook and acceptable-use policy acknowledged.

Offboarding checklist

• All accounts disabled on the effective date (immediately if involuntary).
• Access revoked across SaaS, VPN, building, and third-party systems.
• Devices reclaimed; company data wiped from any personal devices.
• Shared credentials, service accounts, API keys, and SSH keys rotated.
• Mailbox and file ownership transferred; access report reviewed.

Developer security checklist

• No secrets in code, config, or images; use the vault and secret scanning.
• Every change peer-reviewed and passing SAST/DAST/SCA checks.
• Parameterised queries; validate input, encode output.
• Dependencies tracked (SBOM) and patched; no known-vulnerable libraries.
• No real production/personal data in dev or test environments.
• Production access just-in-time, approved, time-boxed, and logged.

Backup and recovery checklist

• 3-2-1-1-0: three copies, two media, one off-site, one immutable, zero errors.
• Backups encrypted and on an isolated credential / access path.
• SaaS data (mail, files, code) backed up - not assumed safe by default.
• Restore tests performed and recovery time measured.
• DR plan documented, stored out-of-band, and rehearsed at least yearly.

Roles and Responsibilities

Security works when everyone knows their part. These responsibilities overlap and reinforce one another - the goal is shared ownership, not buck-passing.

Glossary of Key Terms

Common security terms used in this handbook, in plain language.

Document Control

This handbook is maintained by Information Security and reviewed at least annually and after any major change or significant incident. Questions, suggestions, and reports of anything unclear or out of date are welcome and should be sent to the security team.