Information Security Policy¶


Code	`DT-001`
Domain	Data & Technology
Owner	Chief Information Security Officer
Status	Draft
Applicability	Platform
Jurisdiction	NZ + AU
Business domain	BD09
Review date	2027-03-25

Regulations: CPS 234 Information Security · DTA Outsourcing Standard · NZISM · ISO 27001 ¶

Purpose¶

Govern the platform's data governance framework, including data ownership, classification, quality standards, and lifecycle management.

Scope¶

All data assets created, collected, processed, or stored by the platform across NZ and AU, including customer data, transaction data, and regulatory reporting data.

Policy statements¶

The platform SHALL maintain a data catalogue that identifies all material data assets, their owners, classification, retention period, and primary system of record. The catalogue SHALL be kept current and reviewed at least annually by the Chief Data Officer (CDO).

Every material data asset SHALL have a designated data owner who is accountable for its accuracy, completeness, and fitness for purpose. Data owners SHALL be assigned at the executive or senior management level. Where a data asset crosses multiple domains, a lead data owner SHALL be designated with accountability for cross-domain consistency.

Data assets SHALL be classified according to the platform's data classification schema: Public, Internal, Confidential, and Restricted. Classification SHALL determine access controls, encryption requirements, and handling procedures. Data owners are responsible for assigning and maintaining the correct classification for assets under their ownership.

The platform SHALL enforce data quality standards at the point of ingestion. Data that fails quality rules SHALL be quarantined and SHALL NOT be silently accepted into production systems. Data quality failures affecting regulatory reporting SHALL be escalated to the relevant data owner within four hours of detection.

Data retention periods SHALL be set in accordance with regulatory requirements and the platform's retention schedule. Data SHALL be deleted at the end of its retention period in accordance with a documented deletion procedure. Exceptions to the standard retention period SHALL require written approval from the CDO and the General Counsel.

All changes to data structures, schemas, or pipelines that affect regulated data SHALL go through a change management process that includes data owner sign-off and an impact assessment for downstream reporting. Changes that alter the meaning or derivation of a regulatory reporting metric SHALL be notified to the relevant regulator where required by applicable rules.

The data governance framework SHALL be reviewed annually by the CDO and approved by the Board. Material deficiencies identified through data quality monitoring SHALL be reported to the Board Risk Committee within 30 days of identification.

Satisfying modules¶

Module	Name	Mode	Description
MOD-024	Device & session intelligence	`GATE`	Unauthorised device access detected and challenged without human SOC involvement
MOD-043	EventBridge domain event governance	`AUTO`	EventBridge bus access governed by IAM resource policies — only authorised Lambda functions may publish or subscribe
MOD-044	JWT role-based access control	`GATE`	Least-privilege enforced at API gateway — no client-side security reliance
MOD-045	Secrets & key management	`AUTO`	Secrets cannot be extracted by developers — vaulted and access-controlled
MOD-046	Privileged access management (PAM)	`GATE`	No standing production access — every session is approved, time-limited, and logged
MOD-052	Role-scoped data access	`GATE`	Minimum necessary data access enforced at API — no role can access data outside their scope
MOD-075	Internal API gateway	`GATE`	All service-to-service traffic passes through TLS-terminated endpoints with mutual authentication — no plaintext internal API calls are permitted.
MOD-079	Snowflake decision publication service	`GATE`	Only schema-version-validated, policy-sanctioned outcomes cross the Snowflake → Neon boundary — raw features and intermediate scores never leave Snowflake.
MOD-102	Snowflake account configuration & governance	`GATE`	Snowflake RBAC roles enforce schema-level access boundaries — no system domain can read another domain's raw tables without an explicit cross-domain read grant reviewed by the data governance board.
MOD-103	Neon database platform bootstrap	`GATE`	Each system domain is provisioned with its own Postgres database and role — cross-domain direct DB connections are structurally prevented by the role provisioning model.
MOD-124	Physical card issuance and bureau integration	`GATE`	PIN set and PIN change operations forward encrypted PIN blocks to the processor's HSM via MOD-124's PIN management abstraction — PINs are never in plaintext within bank systems at any point in the processing chain.
MOD-176	Snowflake read API service	`GATE`	All inbound queries pass through TLS-terminated, JWT-authenticated endpoints — no Snowflake credentials are exposed to calling services or the browser.
MOD-177	SD06 risk dashboard renderer	`GATE`	All Snowflake metric queries and write-back requests pass through authenticated, TLS-terminated internal API calls — no Snowflake credentials or database credentials exist in the browser.

Part of Data & Technology · Governance overview Compiled 2026-05-22 from source/entities/policies/DT-001.yaml