[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 the 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 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 manual deactivation.

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

5. Security by Design: Hardened access paths (eg. 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/personnel:

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

---

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 per application/tool across all of HealthSafe.

• Strong Authentication: MFA required.

• Session Recording: Access requests 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 datestamps.

• Approver identity and method of authentication.

Logs are reviewed regularly, and all emergency (break-glass) access on a more frequent basis.

---

9. Standard Access Workflows

Customer Support (SecurePass Super Admin)

1. Case raised and logged with justification and customer.

2. Access production and execute the task(s).

3. Communicate to the client the action taken.

4. Logout at the end of working day or lock your computer screen if you need to step away.

Engineering / Developer (Production Access)

1. Triggered by incident or defect either from a client via support ticket/call or a known internal issue requiring urgent attention.

2. Incident/issue is logged in Hubspot and escalated and logged in JIRA if required.

3. Notify Putti for P1/P2 incidents immediately. 

4. If infrastructure tasks are required, then a request is sent to HealthSafe to allow temporary access to production for Perry and Peter, whereas Henry from Putti has permanent access as he resides in NZ.

5. Include incident summary in post-incident review and communicate to the appropriate parties involved.

Emergency (Break-glass) Access

• Used only to prevent major outage or security risk.

• Requires dual authorisation for Perry and Peter (On-call + Security).

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

---

10. Training & Sandbox Use

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

• Any use of live data requires written consent and HealthSafe approval.

---

11. Data Handling & Retention

• No local storage of customer data unless encrypted or approved by HealthSafe.

• Temporary artifacts (logs, exports) locally should be deleted from local machine within 30 days and only used for the purposes of investigating.

---

12. Customer Notification

Notify customers if:

• Sensitive data have been accessed without authorisation;

• A data leak 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 and logged or contracted per engagement.

---

14. Exceptions

Exceptions require written approval by authorised HealthSafe member, 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

• Software/Repository Access Request Form