Holmes Group Information Security Policies¶
A layered security and AI governance policy set for Holmes Group, a ~500-person international AEC engineering practice operating in New Zealand, Australia, the USA, and the Netherlands.
Everyone reads the Framework once and the Acceptable Use Policy. The numbered control policies are for System Owners, IT, and the security function. Each is written so an MD, a lawyer, a SOC engineer, a CIO, and a graduate engineer can follow it, with a plain opening, a control table, and legal and jurisdictional notes.
The set¶
| # | Policy | Primary audience | Covers |
|---|---|---|---|
| 00 | Framework & Definitions | Everyone, once | Definitions, MUST/SHOULD, roles, exceptions, enforcement, review |
| 01 | Acceptable Use | All staff | Day-to-day behaviour with Holmes technology and information |
| 02 | Information Classification & Handling | All staff and owners | The three levels, personal-information overlay, handling, retention |
| 03 | Identity & Access Management | IT and staff | Authentication, MFA, privileged access, non-human identities |
| 04 | Cloud & Third-Party Services | IT and owners | Service approval, tenant baseline, supplier risk, client assurance |
| 05 | AI Systems Usage | All staff and builders | Approved-tool use, output review, deploying and agentic AI |
| 06 | Endpoint & Mobile Devices | IT and staff | Managed devices, BYOD, encryption, loss, removable media |
| 07 | Network & Infrastructure Security | IT | Segmentation, legacy protocols, wireless, firewalls, PKI |
| 08 | Email & Messaging Security | IT and staff | User rules, SPF/DKIM/DMARC, anti-phishing |
| 09 | Secure Development & CI/CD | Developers and IT | Pipelines, dependencies, secrets, code review |
| 10 | Vulnerability & Patch Management | IT | Scanning, penetration testing, remediation SLAs, patching |
| 11 | Logging, Monitoring & Detection | IT and SOC | What's logged, retention, detection, the security function |
| 12 | Incident Response | Everyone (report) and the response team | Reporting, response lifecycle, breach notification |
| 13 | Physical Security | Facilities and IT | Premises, server rooms, clear desk |
How the set works¶
It's layered. Definitions, roles, the MUST/SHOULD convention, the exceptions process, and enforcement live only in the Framework. The other policies reference them rather than restating them, so they can't drift out of sync.
Classification is the spine. Three levels, PUBLIC, CONFIDENTIAL (the default), and RESTRICTED, plus a personal-information overlay for privacy law, defined in 02. Most controls key their depth to the classification level.
It's written for five readers. Plain openings for the MD and graduate, control tables for the CIO and SOC engineer, and legal and jurisdictional notes for the lawyer, spanning NZ, AU, US, and EU.
Where a control can't be technically guaranteed, the policy says so rather than implying a boundary that isn't there. See personal AI use in 05.
Draft status¶
This is draft v0.1. Before adoption:
- Reviewer pass on the substance and readability.
- Counsel review, concentrated in 02 (retention, CUI/ITAR), 04 (contract terms), 05 (AI reliance), 06 (BYOD), 11 (monitoring), and above all 12 Incident Response (breach-notification thresholds).
- Set the indicative numbers, remediation SLAs, retention periods, and review dates, for the CIO and TOP to ratify.
- Establish or name the security function or SOC so references resolve to something real (11 LOG.9, LOG.10).
- Approve, version, and set the annual review calendar.
The analysis behind this set, including the feedback and posture findings that informed it, is kept separately as internal working material and isn't published here.