# PiP Pilot Assurance and Readiness Gates

**Research cut-off:** 4 August 2026
**Status:** Public-source product diligence
**Purpose:** Define the evidence required before PiP moves from public demo to community, village, HCSS or Health NZ use

## Executive read

PiP is suitable for controlled discovery and a low-data community pilot, but it is not yet publicly evidenced as procurement-ready village or health infrastructure. Its public pilot-stage disclosure is appropriately candid. The next credibility step is a buyer-ready assurance pack proving privacy, accessibility, authentication, incident continuity, support capacity and exit portability.

Product-page statements such as AWS hosting, audit logs, role-based access, “privacy-first analytics,” tenant separation and “MFA ready” are vendor claims. They are not certifications or evidence that controls have been independently tested.

## Public diligence findings

PiP publicly describes resident, family, staff and operator functions spanning events, notices, photos, welfare checks, incidents, rosters, maintenance, family notes, automated summaries and virtual-assistant features. This creates personal, inferred and potentially health information even when the proposition is described as non-clinical.

At the research cut-off:

- the public `/privacy` and `/terms` routes returned 404;
- no linked privacy notice was visible beside the demo form;
- no public AWS region, backup region, subprocessor or cross-border-processing schedule was located;
- no public retention, access, correction, export or deletion procedure was located;
- no independent penetration test, vulnerability process, incident terms, restore evidence, RTO/RPO, accessibility conformance report or support SLA was located;
- no public AI provider, prompt-retention, model-training or human-review specification was located;
- PiP correctly disclosed that it was in pilot and had no published case studies or verified customer outcomes.

These are gaps in public evidence, not proof that internal controls do not exist.

## Priority risk boundaries

### Privacy and indirect collection

New Zealand's Privacy Act principles cover purpose, notice, security, access/correction, accuracy, retention, use, disclosure, overseas disclosure and identifiers. Since 1 May 2026, IPP3A notification obligations also cover personal information collected indirectly.

That matters for family-written notes, staff-entered welfare or incident records, imported resident data, partner attendance/referral information and automated summaries derived from another person's input.

Calling PiP non-clinical does not remove health-information obligations. Welfare, support, mobility, incident and participation patterns may reveal sensitive information, and rest homes, supported accommodation and disability-support providers may be health agencies under the Health Information Privacy Code.

### Authentication

First name plus a four-digit resident PIN is a usability proposition, not sufficient assurance. PiP must document duplicate-name handling, enumeration and brute-force protection, attempt limits, lockout, session timeout, shoulder-surfing risk, credential recovery, shared/lost-device response and step-up authentication.

“MFA ready” must not be represented as deployed MFA. Staff, operator and privileged accounts should enforce MFA before handling operational personal information.

### Public Display Hub

The pre-login Display Hub requires a separate public-information classification. Birthdays, photos, occupancy clues, resident alerts, transport, welfare or absence information need explicit opt-in, revocation and safe defaults.

### Automation and AI

PiP should identify which automations are deterministic and which use AI, the model and hosting provider, data sent in prompts, retention/training position, prohibited content, human approval rules, error testing, monitoring and rollback. Sensitive updates should require human approval until a documented risk model establishes otherwise.

### Accessibility and non-digital service

Large text, font controls and read-aloud features do not prove accessibility. WCAG 2.2 AA is the credible procurement baseline. Evidence should include keyboard, focus, screen-reader, zoom/reflow, contrast, target-size, cognitive-accessibility, plain-language and disabled older-user testing.

Every pilot must preserve printed information, telephone and reception requests, staff-assisted booking, face-to-face complaints, manual emergency/welfare processes and an outage procedure. Non-users must not receive reduced service.

### Retirement-village and health boundaries

PiP cannot become the only channel for statutory notices, complaints, urgent alerts, resident consultation or essential village services. For HCSS or Health NZ, organisation, product and product–data-use-case assurance are separate gates. Phase one should remain non-clinical and zero-integration.

## Minimum evidence pack

1. Legal entity, ownership, directors and accountable product, privacy and security leads.
2. Privacy notice, terms and data-processing agreement.
3. Controller/processor responsibility matrix and HIPC assessment.
4. Full data inventory, flow diagram and minimum-field register.
5. IPP3/IPP3A notices, consent and proxy/representative model.
6. Privacy impact assessment, security risk assessment, system security plan and threat model.
7. AWS architecture, regions, backups, subprocessors and jurisdictions.
8. Encryption, tenant-isolation and key-management description.
9. Role matrix, enforced staff/admin MFA and resident-PIN threat model.
10. Secure-development policy, SBOM, vulnerability process and independent penetration test.
11. Incident plan, customer-notification SLA and tested breach exercise.
12. Backup restoration evidence, BCP/DR and RTO/RPO.
13. WCAG 2.2 AA report plus manual disabled and older-user testing.
14. Accessibility statement and non-digital continuity plan.
15. Support hours, response/escalation targets, onboarding and training model.
16. Export schema, termination assistance and deletion certificate, including backups.
17. AI/automation inventory, providers, human review, retention and accuracy tests.
18. Insurance, financial continuity and key-person or escrow contingency.
19. Pilot measurement plan covering user outcomes and staff support burden.

## Staged readiness gates

### Gate 0 — public demo

- Publish privacy notice and terms and link them beside every form.
- Remove draft/test content and clarify pilot-stage claim boundaries.
- Use dummy data only.
- Publish contact, complaint and correction routes.
- State that PiP is non-clinical and not an emergency system.

### Gate 1 — community, church or council discovery pilot

Scope public directory, events, activities, minimal contact data and aggregate feedback only.

Required evidence:

- PIA-lite and data flow;
- IPP3A mapping;
- WCAG 2.2 AA testing;
- phone, print and assisted alternatives;
- basic penetration test;
- incident, support, export and deletion plan;
- consent-based pilot agreement.

Exclude welfare, incidents, detailed family information and health records.

### Gate 2 — retirement-village operational pilot

Add:

- signed DPA and full PIA;
- active MFA for staff/admin and tested resident-PIN controls;
- family access and revocation workflow;
- photo, birthday and public-display consent;
- tenant-isolation and independent penetration tests;
- backup restore and outage exercise;
- support SLA and workload baseline;
- export/deletion test;
- non-digital complaints and urgent-communication continuity.

Keep welfare and incidents out until the operator confirms the source of truth, escalation, HIPC and liability ownership.

### Gate 3 — HCSS provider pilot

Add:

- formal HIPC and Ngā Paerewa assessment;
- supported-decision-making and consent model;
- cultural and Māori data-governance review;
- provider-owned workflow and failed-referral escalation;
- aggregate-only outcomes and health-sector incident terms;
- independent security assurance and tested continuity.

Keep clinical records and provider-system integration out of scope.

### Gate 4 — Health NZ integration

Only after a justified interoperability need:

- HISO gap closure;
- Health NZ organisation, product and use-case onboarding;
- SPICE review;
- formal information-sharing approval;
- identity and API assurance;
- testing/UAT evidence;
- accessibility and equity approval;
- supplier/subprocessor diligence;
- recertification and full exit/deletion arrangements.

## Cross-meeting application

- **Health NZ and HCSS:** bring the Gate 1–3 roadmap, not a claim of infrastructure readiness.
- **Selwyn Village:** complete Gate 2 before operational resident, family, welfare or incident use.
- **The Selwyn Foundation:** present assurance work as a costed evidence programme, not as completed diligence.
- **Councils and connected communities:** Gate 1 is achievable if assisted and non-digital access is funded.
- **Active Seniors:** any QR or editorial capture page requires Gate 0 privacy, consent, accessibility and minimal-data treatment.

## Source register

- PiP — Home: https://peopleinplace.co.nz/
- PiP — Customers and pilot status: https://peopleinplace.co.nz/customers
- PiP — Security: https://peopleinplace.co.nz/security
- PiP — Display Hub: https://peopleinplace.co.nz/display-hub
- Office of the Privacy Commissioner — Privacy principles: https://www.privacy.org.nz/privacy-principles/
- Office of the Privacy Commissioner — Working with third-party providers: https://www.privacy.org.nz/resources-and-learning/a-z-topics/working-with-third-party-providers/
- Office of the Privacy Commissioner — Privacy breaches: https://www.privacy.org.nz/responsibilities/privacy-breaches/notify-us/
- Office of the Privacy Commissioner — AI guidance: https://www.privacy.org.nz/resources-and-learning/a-z-topics/ai/
- Office of the Privacy Commissioner — Health Information Privacy Code: https://www.privacy.org.nz/privacy-principles/codes-of-practice/hipc2020/
- Digital.govt.nz — Web Accessibility Standard 1.2: https://www.digital.govt.nz/standards-and-guidance/nz-government-web-standards/web-accessibility-standard-1-2
- Digital.govt.nz — Inclusive and equitable services: https://www.digital.govt.nz/standards-and-guidance/digital-service-design-standard/principles/be-inclusive-and-provide-ethical-and-equitable-services
- Digital.govt.nz — Cloud jurisdictional risk: https://www.digital.govt.nz/standards-and-guidance/technology-and-architecture/cloud-services/assess-the-risks/cloud-jurisdictional-risk-guidance
- Health NZ — Digital Services Hub onboarding: https://www.healthnz.govt.nz/health-professionals/guidance-standards/topic/digital-technologies/digital-services-hub/for-it-vendors-and-developers/onboarding-assessments
- Health NZ — Generative AI guidance: https://www.healthnz.govt.nz/health-professionals/guidance-standards/topic/digital-technologies/using-generative-ai-and-large-language-models
- Ministry of Health — Ngā Paerewa guidance: https://www.health.govt.nz/publications/sector-guidance-for-nga-paerewa-health-and-disability-services-standard-nzs-81342021
- Retirement Commission — Retirement Villages Code of Practice: https://retirement.govt.nz/retirement-villages/the-act-regulations-and-codes/code-of-practice
- New Zealand Government Procurement — Supplier due diligence: https://www.procurement.govt.nz/guides/guide-to-procurement/source-your-suppliers/conducting-due-diligence-checks/
- New Zealand Government Procurement — Third-party personal information standard: https://www.procurement.govt.nz/about-us/news/new-standard-for-accessing-and-collecting-of-personal-information/

## Evidence classification

- **Public product claim:** stated by PiP but not independently tested for this brief.
- **Verified public requirement:** supported by an official regulator, government or standards source.
- **Strategic gate:** a recommended minimum before entering the named pilot stage.
- **Unresolved:** evidence was not located publicly and must be supplied during diligence.