[DRAFT] 37. Customer Data Access Policy (Support & Production)

Document Identification	HSNZ/POL/37
Document Name	Customer Data Access Policy
Master Copy	CISO
Version Number	1.0
Date Of Release	20 Oct 2025
Prepared By	Eparama Tuibenau	CISO
Approved by	Gideon Burke	CEO

 

VERSION HISTORY

Sl No	Version No.		Prepared by	Approved by	Description of Version	Date	Reason for Version Change
	From	To
1	1.0	-	CISO	CEO	Current	20 Oct 2025	Release

DOCUMENT STATUS

Date	Document Status
20 Oct 2025	Released

Table of Contents

1 Purpose

2 Scope

3 Input

4 Output

5 Interacting Process

6 Abbreviations, Acronyms and Definitions

7 Procedure

8 Monitoring the Process

9 Records

 

---

1. Purpose

This policy defines when, why, and how HealthSafe personnel and approved partners may access customer data within SecurePass or other HealthSafe SaaS production environments.

Access is by exception only, and must be:

• Justified by a permitted business purpose;

• Approved through formal workflow;

• Time-bound and least privilege; and

• Logged, auditable, and reviewed.

The policy supports ISO/IEC 27001 controls (A.5, A.8, A.9, A.12, A.18) and privacy laws, and ensures customers such as the Reserve Bank of New Zealand (RBNZ) can rely on robust and transparent access control practices.

---

2. Scope

This policy applies to:

• All HealthSafe employees and contractors with potential access to customer data in SecurePass or related systems (e.g., ticketing, observability, backups).

• Customer Support, Engineering, SRE/DevOps, Security, and Compliance teams.

• Approved third-party partners (e.g., Putti Apps) who may support production services under HealthSafe’s direction.

---

3. Definitions

• Customer Data: Any information input, processed, or generated by customers within SecurePass or other HealthSafe SaaS platforms.

• Access: The ability to view, query, retrieve, modify, or delete customer data or metadata.

• Just-In-Time (JIT) Access: Temporary, scoped, approved access granted for a specific purpose and duration.

• Break-glass Access: Emergency access authorised to prevent or mitigate major incidents.

• Least Privilege: Granting the minimum rights necessary to perform a task.

---

4. Guiding Principles

1. Necessity & Proportionality: Only access what is strictly needed.

2. Transparency: All access must be ticketed, approved, and logged.

3. Least Privilege & Time-Bound: Default is no access; JIT with auto-expiry.

4. Data Minimisation: Use redacted or masked data where possible.

5. Security by Design: Hardened access paths (bastions, PAM, MFA).

6. Customer Trust: Notify customers where required by contract or regulation.

---

5. Permitted Reasons for Access

Access is permitted only for the following business-justified purposes:

Explicitly prohibited: convenience access, curiosity, research without consent, or performance review without need.

---

6. Roles & Responsibilities

---

7. Access Control Requirements

• Default Deny: No standing access by default.

• Just-In-Time Access: Maximum 8 hours unless extended with justification.

• Scoped & Role-Based: Access limited to a single customer tenant or dataset.

• Strong Authentication: MFA required; hardware keys preferred.

• Session Recording: Commands and queries recorded where feasible.

• Permanent Access: Only two authorised production administrators (NZ/AU-based) hold credentials for continuity.

---

8. Logging & Audit

All access is logged with:

• User identity, ticket ID, purpose, system accessed, and timestamps.

• Approver identity and method of authentication.

• Queries and objects viewed/exported.

Logs are reviewed quarterly, and all emergency (break-glass) access within 3 business days.

---

9. Standard Access Workflows

Customer Support (SecurePass Super Admin)

1. Case raised and logged with justification and customer ID.

2. Check customer’s access consent settings (e.g., contractual opt-outs).

3. Submit access request for approval by Support Lead.

4. Access via in-product “impersonation” or tenant-scoped tools.

5. Document findings; delete temporary data.

6. Notify customer where required.

Engineering / Developer (Production Access)

1. Triggered by incident or defect requiring real-data verification.

2. Document purpose, scope, and duration.

3. EM/on-call approval; Security informed for P1/P2 incidents.

4. Use read-only replicas where possible.

5. Encrypt and auto-expire any necessary data exports.

6. Include access summary in post-incident review.

Emergency (Break-glass) Access

• Used only to prevent major outage or security risk.

• Requires dual authorisation (On-call + Security).

• Duration ≤ 2 hours; fully logged and reviewed post-incident.

---

10. Training & Sandbox Use

• All non-production work (QA, training, testing) must use synthetic or masked data.

• Any use of live data requires written customer consent, DPO approval, and data deletion after use.

---

11. Data Handling & Retention

• No local storage of customer data unless encrypted and approved.

• Temporary artifacts (logs, exports) expire within 30 days.

• Backup access follows this policy and is logged.

---

12. Customer Notification

Notify customers when:

• Manual data export occurs;

• Sensitive data categories are accessed;

• A security incident or contract-defined trigger occurs.

---

13. Third-Party & Partner Access

• Subprocessors (e.g., Putti Apps) must adhere to equivalent controls and contractual DPAs.

• Partner access is restricted to NZ-based approved IP ranges and logged per engagement.

---

14. Exceptions

Exceptions require written approval by Security, DPO, and relevant VP, with expiry date and compensating controls.

---

15. Enforcement

Violations may result in disciplinary action up to and including termination, and may be reportable to customers or regulators.

---

16. References

• Information Security Policy

• Access Control Standard

• Data Classification & Handling Standard

• Incident Response Plan

• Vendor Management Standard

• Privacy Policy

• Record Retention Schedule