Information Classification & Handling¶
Almost everything Holmes holds is confidential: client drawings, reports, contracts, our own commercial information. This policy sorts information into three sensitivity levels so you know how carefully to handle each, and it flags personal information for extra care because the law requires it. The default is simple. Treat Holmes and client information as Confidential unless it's clearly public or clearly needs locking down further.
This is the single source of truth for classification across the policy set. Terms like MUST, SHOULD, and System Owner are defined in the Framework.
1. Principles¶
Confidential is the default. Nearly all Holmes and client information carries some confidentiality obligation, so treat information as Confidential unless it's clearly public or clearly needs locking down further. There are three sensitivity levels, PUBLIC, CONFIDENTIAL, and RESTRICTED. Personal information sits across all three as an overlay, because it can appear at any level and privacy law applies wherever it does.
2. Classification levels¶
| Level | Meaning | Examples | Default? |
|---|---|---|---|
| PUBLIC | Published, or approved for publication, to anyone outside Holmes. Integrity still matters (we don't want it altered) but disclosure causes no harm. | Website content, published papers, marketing, tender material once public | No |
| CONFIDENTIAL | The default for all Holmes and client business information. Not for public release, but freely accessible to Holmes staff on a reasonable business basis. Disclosure could harm Holmes, a client, or a project. | Client project files, drawings, reports, contracts, internal documents, methodologies, most email | Yes |
| RESTRICTED | Confidential information whose access is limited to specific authorised people or roles. Disclosure could cause serious harm: legal, commercial, safety, or contractual. | Restricted-access projects (defence, prisons, critical infrastructure, banks), M&A and board material, commercial product IP, security configuration, US CUI or ITAR-controlled technical data | No |
Rule of thumb: if you're not sure, it's Confidential. If a client, a contract, or common sense says only certain people should see it, it's Restricted, so ask the System Owner.
The personal information overlay. Anything about an identifiable person is handled as Confidential at a minimum, and Restricted where it's sensitive (health, financial, biometric, or anything whose disclosure could seriously harm someone). Employee records are Restricted and owned by People & Culture. Personal information also triggers privacy-law obligations (section 6) whatever its classification. It's an overlay rather than a fourth tier because personal data can appear at any level, and the extra rules apply wherever it does.
3. Handling requirements by level¶
| Ref | Requirement | Level | Notes |
|---|---|---|---|
| IC.1 | Information MUST be classified by its System Owner, or by the creator using the rule of thumb above. | All | Classify at creation. |
| IC.2 | CONFIDENTIAL and RESTRICTED information MUST be stored only on approved systems (04). | Conf/Restr | No personal cloud, personal email, or unapproved AI (01, 05). |
| IC.3 | Access to RESTRICTED information MUST follow least privilege, limited to named roles, reviewed at least annually. | Restr | Ties to 03 IAM. |
| IC.4 | CONFIDENTIAL and RESTRICTED information sent outside Holmes MUST use encrypted channels: approved file-share links or encrypted transfer, not email attachments for RESTRICTED. | Conf/Restr | Approved channels are OneDrive/SharePoint and equivalents. See section 5 on inbound email. |
| IC.5 | Encryption MUST protect CONFIDENTIAL and RESTRICTED information in transit (TLS 1.2+) and at rest (AES-256 or equivalent) on Holmes-managed systems. | Conf/Restr | Backs the encryption commitment in the client assurance statement (04). |
| IC.6 | Physical CONFIDENTIAL or RESTRICTED documents MUST be secured when unattended: locked storage on site, out of sight and secured off-site. | Conf/Restr | Scoped to what each office can actually achieve (13). |
| IC.7 | Information MUST be disposed of so reconstruction isn't reasonably possible: secure deletion for digital, shredding or equivalent for physical. | All | Covers digital and physical media. |
| IC.8 | RESTRICTED information SHOULD be marked or labelled (footer, metadata, or sensitivity label) so its handling is unambiguous. | Restr | Uses the published sensitivity labels (section 4). |
4. Making classification real¶
A classification scheme with no technical backing is a set of hopes. The controls below give the levels teeth, so the rules above can be enforced and evidenced rather than relying on goodwill.
| Ref | Requirement | Notes |
|---|---|---|
| IC.9 | Sensitivity labels (Purview) MUST be published, mapped to the three levels, and available in Office and email. | The labels are the user-facing form of this policy. |
| IC.10 | DLP policies MUST be enabled to detect and control movement of RESTRICTED and personal information out of approved boundaries. | Closes the highest-leakage gap and underpins the AI "public-only" boundary in 05. |
| IC.11 | External-sender tagging SHOULD be enabled to help staff spot information leaving or entering Holmes. | Supports 08 Email. |
5. Guidance for staff¶
Received confidential material by email? File it into the project system, which is the system of record. Receiving it is fine. Leaving it unmanaged in your mailbox, where it stays unprotected and badly retained, isn't.
Sending to a client or partner? Use an approved share link, not an attachment, for anything Restricted. For Confidential, follow the client's agreed method.
Inter-practice confidentiality. Where clients aren't shared between practices, treat their information as Restricted to the relevant practice. If you're unsure whether another practice should see something, ask first.
Personal information. If it's about a person and isn't already public, it's at least Confidential. If it's sensitive (health, pay, ID documents), it's Restricted and usually P+C's to hold.
6. Records retention¶
Retention is driven by professional-liability and statutory periods, not by keeping everything forever. Indefinite retention conflicts with privacy-law minimisation and increases breach exposure.
| Ref | Requirement | Notes |
|---|---|---|
| IC.12 | Business records MUST be kept for the period required by statute, professional-liability limitation, and contract, and no longer than justified. | AEC limitation periods are long (for example NZ's 10-year Building Act longstop), which is the real driver. Retention schedule to be confirmed with counsel per jurisdiction. |
| IC.13 | Personal information MUST NOT be kept longer than the purpose requires. | NZ IPP9, GDPR storage limitation, AU APPs. |
| IC.14 | A retention schedule SHOULD be maintained by System Owners with Legal, covering record type, minimum retention, and disposal trigger. | Gives owners a concrete basis for disposal decisions. |
7. Legal & jurisdictional notes¶
RESTRICTED is the handling home for regulated categories: personal information at scale, health information (NZ Health Information Privacy Code), and US CUI or ITAR/EAR-controlled technical data on defence-adjacent projects. That last category may also require US-person access controls and US data residency. Confirm applicability per engagement with Legal.
Cross-border transfer of personal information, for example NZ or AU project data processed in a US or EU region, is constrained by NZ IPP12, GDPR Chapter V, and the APPs. Data-residency requirements flow from this into 04 Cloud & Third-Party.
Counsel review is needed on the retention schedule (IC.12) and the CUI/ITAR handling position before finalisation.
Related policies¶
00 Framework, 01 Acceptable Use, 04 Cloud & Third-Party, 05 AI Systems, 08 Email & Messaging, 12 Incident Response.