Information Security Policy Framework¶
This is the front page of Holmes' security rules. It sets out who the rules cover, how to read them, what the key terms mean, who's responsible for what, and what to do when a rule can't be met. Read it once. You won't need to re-read the definitions in the other policies because they live here and nowhere else.
1. Purpose¶
This Framework is the parent document for Holmes' security policies. It exists so that staff know what's expected of them, IT and security engineers have a control set they can build and audit against, executives and directors can see that risk is governed sensibly, and clients and their lawyers can be shown how their data is handled.
2. Why we have it¶
Holmes' reliance on digital, cloud, and now AI systems keeps growing, and so does its exposure. These policies exist to manage that risk in a way that's current, proportionate, and written to be understood.
We're an engineering consultancy, not a bank. The target is sound, defensible, mid-to-high maturity, with controls matched to the sensitivity of the work. Where a control is disproportionate, use the exceptions process in section 7 rather than quietly ignoring it.
3. Scope¶
Covers all Holmes Group companies and subsidiaries; all employees, contractors, secondees, and temporary staff; and all information and systems Holmes owns, operates, or is trusted with, wherever they're hosted. Geographic reach and the laws that bind us are in section 8.
4. How the set is structured¶
The set is layered so each reader meets the right level of detail.
| Layer | Documents | For |
|---|---|---|
| Framework (this document) | ISF | Everyone, read once |
| Acceptable Use | 01 Acceptable Use | All staff. The day-to-day behaviour layer |
| Control policies | 02 to 13 | System owners, IT, security engineers. The auditable control detail, with staff guidance where it's relevant |
Read the Acceptable Use Policy and you've covered everything that governs your own behaviour. The control policies carry the detail that owners and IT implement, and each links back to the behaviour rule it supports.
Definitions, the classification scheme, the MUST/SHOULD convention, roles, the exceptions process, and the enforcement statement appear only here. The other policies point to them rather than restating them, so they can't drift out of sync.
5. How to read a requirement: MUST and SHOULD¶
Two words carry precise meaning. The distinction matters for audit, certification, and client assurance, so we keep it.
MUST means mandatory. It can only be waived by written CIO approval through the exceptions process (section 7), recorded case by case.
SHOULD means strongly recommended. It can be waived where a specific low-risk situation or a genuine constraint applies, for example a control a packaged application can't support. Ask your manager or the CIO if you're unsure.
"MUST NOT" and "SHOULD NOT" are the prohibitions. Anything not marked is guidance, not a control.
6. Definitions¶
| Term | Meaning |
|---|---|
| Information | Any data Holmes creates, receives, or holds, in any form: digital, physical, or spoken. |
| Classification | The sensitivity label on information: PUBLIC, CONFIDENTIAL, or RESTRICTED. Defined in 02 Information Classification & Handling. |
| Personal Information | Information about an identifiable living person. Handled as an overlay on classification (see 02) and governed by privacy law (section 8). |
| System Owner | The person accountable for a system or dataset: its classification, access, risk assessment, and periodic review. Usually a business or practice lead, supported by IT. |
| AI System | Any AI or machine-learning technology (LLMs, generative AI, agents, embedded AI features) that processes, stores, or transmits Holmes information. See 05 AI Systems Usage. |
| Non-human identity | Any credential or account not tied to a person: service accounts, API keys, tokens, certificates, managed identities, AI agents. |
| CIO | Chief Information Officer. Accountable owner of this Framework. |
| Security function / SOC | The people and services that monitor and respond to security events, as defined in 11 Logging, Monitoring & Detection, whether staffed internally, by a provider, or both. If no such capability is currently contracted, references resolve to the CIO and IT security team until one exists. |
7. Exceptions and waivers¶
No control set fits every case. When a MUST can't be met:
- The System Owner or affected staff member raises an exception request with IT, stating the control, why it can't be met, the compensating measures proposed, and a review date.
- The CIO or delegate approves or declines in writing.
- Approved exceptions go in a register with an expiry date and are revisited at expiry.
An unapproved deviation is a breach (section 9). An approved, recorded, time-boxed exception is normal risk management. The difference is the paperwork, and the paperwork is the point.
8. Legal and jurisdictional context¶
Holmes operates in four jurisdictions. The policies are written to hold up across all of them. The obligations below shape them. This section states policy positions, not legal advice. The breach-notification thresholds, retention periods, and cross-border rules must be confirmed with counsel before the set is finalised.
New Zealand: Privacy Act 2020, with 13 Information Privacy Principles and mandatory notification to the Privacy Commissioner and affected individuals where a breach is likely to cause serious harm. Building Act limitation periods (a 10-year longstop) drive engineering-records retention.
Australia: Privacy Act 1988 and the Australian Privacy Principles, plus the Notifiable Data Breaches scheme, which requires notifying the OAIC and affected individuals of an eligible data breach. State-based building and limitation periods apply.
United States: no single federal breach law. All 50 states have breach-notification statutes tied to residents' personal information, and California's CCPA/CPRA may apply to some data. Federal or defence-adjacent projects can involve Controlled Unclassified Information or ITAR/EAR-controlled technical data, flagged as RESTRICTED in 02 and potentially requiring US-person access and US data residency.
Netherlands and EU: GDPR applies to the Netherlands entity, covering lawful basis, data-subject rights, cross-border transfer, and 72-hour breach notification to the supervisory authority.
Across all of these, AEC professional-liability and limitation periods are long, which is the real driver of records retention, not indefinite keeping (see 02). Client contracts often impose their own confidentiality and notification terms, which override the defaults where they're stricter (see 12 Incident Response).
9. Roles and responsibilities¶
| Role | Responsibility |
|---|---|
| Board / TOP | Approve the risk appetite and oversee that security risk is governed. |
| CIO | Own this Framework and the set; approve exceptions; ensure annual review; report posture to the Board. |
| Security function / SOC | Monitor, detect, triage, and lead incident response; maintain detection and logging controls. |
| System Owners | Classify their systems and data; ensure risk assessments and access reviews happen; approve access. |
| IT / Systems Engineering | Build and run the controls; maintain the technical baselines; support owners and staff. |
| People & Culture | Own employee personal information; run joiner/mover/leaver processes; hold the disciplinary framework (Holmes Life). |
| Legal / Risk | Advise on breach notifiability, contract obligations, and jurisdictional requirements. |
| All staff | Follow Acceptable Use; report anything suspicious (12); ask when unsure. |
10. Review and maintenance¶
Every policy is reviewed at least annually and after any material change, such as a significant incident, a new regulation, or a major technology shift. The CIO owns the review calendar. A policy that isn't reviewed drifts out of step with the environment and the threats, and stops being worth trusting.
Each policy carries a version, an owner, and a last-reviewed date. A policy past its review date is flagged, not trusted.
11. Enforcement¶
Following these policies is a condition of access to Holmes systems and information. A breach may amount to misconduct or serious misconduct. The process and consequences are governed by the employment framework (Holmes Life) and employment law, not by this document. This is the only enforcement statement in the set. Individual policies don't restate it.
Related documents¶
Index / policy map. All control policies: 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13.