GIWAHS Security & Incident Response Policy

Document: 30 · Legal & Compliance Pack Version: 1.0 – Founder Draft (pre-publication) Status: Authored by AI under Doc 09 Autonomous Execution Standard. MUST be reviewed and signed off by qualified security/data-protection counsel before being shared with customers, auditors, or referenced in contracts. Effective Date: To be inserted on publication. Last Updated: To be inserted on publication. Cross-references: Docs 24 (Privacy Policy §11), 25 (Terms of Service), 29 (DPA), 31 (Subprocessor Register).

Audience: Customers, auditors, regulators, internal engineering. This policy is the source of truth for the technical and organisational measures referenced in Doc 29 Annex B and any Standard Contractual Clauses Annex II.

1. Scope

This Policy describes the administrative, technical, and physical measures Whaitiri Black Limited, a company incorporated in New Zealand, trading as GIWAHS (“GIWAHS”, “we”) takes to protect the confidentiality, integrity, and availability of:

• the GIWAHS Platform (frontend, backend, database, edge functions, supporting services);
• Customer Personal Data and Customer Confidential Information;
• our corporate systems that hold or access the above.

It also defines our Incident Response process — detection, containment, eradication, recovery, notification, and post-incident review — and our notification commitments to Customers, regulators, and affected individuals.

This Policy supports compliance with: - NZ Privacy Act 2020 Information Privacy Principles 5 (Storage and Security) and 12 (Disclosure outside NZ); - EU GDPR / UK GDPR Articles 32 (Security), 33 (Breach Notification to Supervisory Authority), 34 (Breach Notification to Data Subjects); - CCPA/CPRA and other US state privacy laws’ “reasonable security” requirements and breach-notification statutes (US state-by-state laws). - Australia Privacy Act 1988 APP 11 (Security) and the Notifiable Data Breaches scheme.

2. Security Governance

2.1 Ownership

• The Director of Whaitiri Black Limited (trading as GIWAHS), Jay Elkington, has overall accountability for information security.
• A nominated Security Lead (engineering function holder; to be designated in writing) owns day-to-day implementation.
• Jay Elkington is the designated Privacy Officer for the purposes of the NZ Privacy Act 2020 until counsel-advised reassignment.

2.2 Risk management

• Annual risk register review covering: confidentiality, integrity, availability, regulatory exposure, vendor risk, and emerging threats.
• High-risk findings tracked to closure with owner and date.

2.3 Policies and standards

• This Policy and Doc 24/29/31 are reviewed at least annually and after any material incident.
• Internal engineering runbooks and the deployment playbook (Doc 09 derivatives) are maintained in /app/memory/founder_vault/.

2.4 Personnel

• All personnel with production access undergo a documented onboarding including security responsibilities.
• Background checks for engineers granted production access where lawful in their jurisdiction.
• All personnel sign a confidentiality undertaking.
• Annual security-awareness training (phishing, password hygiene, social engineering, secrets handling).

3. Asset Inventory and Classification

4. Access Control

• SSO + MFA mandatory for all corporate identity providers (Google Workspace) and production-impacting tooling (Supabase, Stripe, Cloudflare, GitHub, Resend, OpenAI organisational console).
• Role-based access control (RBAC) in the application via Supabase Row-Level Security policies, the is_admin() function, and SECURITY DEFINER RPCs that explicitly check auth.uid().
• Service-role keys stored only in /app/backend/.env (never in source control); rotation procedure documented; emergency rotation in incident-response runbook.
• Least privilege enforced for engineering: production write access limited to designated engineers; read access scoped to project needs.
• Joiner/Mover/Leaver: access provisioned within 1 business day of role change; access revoked within 24 hours of departure or role change.
• Periodic access reviews: at least quarterly for high-privilege accounts; full review annually.

5. Cryptography

6. Network and Edge Security

• Cloudflare in front of all public traffic: WAF, DDoS mitigation, bot management, rate limiting, IP-reputation filtering, geo-blocking for sanctioned regions.
• Supabase hosts the database and edge functions in customer-isolated tenants behind their hardened ingress; service-role key required for privileged paths.
• Stripe PCI-DSS-compliant infrastructure handles all card data; we never receive raw card numbers.
• Restricted egress for backend processes; outbound calls limited to known Subprocessors (Doc 31).

7. Application Security

• Secure SDLC: code review required for all changes touching auth, billing, RLS, or Personal Data; CI runs lint and tests on every commit.
• Dependency management: automated vulnerability scanning; critical patches applied within 7 days, high within 30 days.
• Secrets management: .env files for runtime; secrets never committed; Supabase / Cloudflare secret stores for production credentials.
• Input validation: all user input validated at trust boundaries; SQL via parameterised queries / RPCs only; outputs escaped in JSX by default.
• OWASP Top 10 reviewed at least annually.
• Webhook security: Stripe and Resend webhooks signature-verified before processing; idempotency keys deduplicate replays.
• CSRF: protected with XSRF-TOKEN cookie + double-submit pattern on state-changing routes.
• CORS: scoped allow-list; wildcard never used in production.

8. Data Protection

• Minimisation: collect only what is required for the purposes in Doc 24 §4 / Doc 29 Annex A.
• Pseudonymisation/de-identification for analytics where feasible.
• Storage location: Supabase (configurable region — primary: AWS region documented to customer on request); Cloudflare global edge; Stripe US-primary with global processing; Resend US-primary; OpenAI US (only if AI features enabled).
• Backups: daily encrypted backups with ≥35-day retention; backup restore tested at least annually.
• Deletion: per Doc 24 §7 and Doc 29 §11; backup tombstoning until rotation.
• AI usage: where AI features are enabled (currently disabled per D-009/D-010), Customer Personal Data is never used to train third-party models; we use API endpoints with no-training and zero-data-retention configurations where available (e.g., OpenAI API endpoints with the no-training default).

9. Logging and Monitoring

• Application logs: structured JSON, retained 13 months.
• Database audit log: administrative actions logged via the audit_log table (per migrations 015–020).
• Edge function logs: retained per Supabase platform defaults.
• Stripe + Resend event logs: retained in those platforms; webhook receipts logged on GIWAHS side.
• Alerts for: failed login spikes, error-rate anomalies, webhook signature failures, cron-job non-completion.
• PII in logs: redacted by default; rare exceptions reviewed and minimised.

10. Business Continuity & Disaster Recovery

Tabletop exercises run annually to validate recovery procedures.

11. Vendor / Subprocessor Risk

• Subprocessors are listed and version-controlled in Doc 31 (Subprocessor Register).
• New Subprocessors undergo a documented intake including: data-protection terms, transfer mechanism (SCCs/IDTA where applicable), security posture (SOC 2 / ISO 27001 if available), and a privacy review.
• Material changes notified 30 days in advance under Doc 29 §6.3.

12. Incident Response

12.1 Definitions

• Security Event — observed anomaly that may warrant investigation.
• Security Incident — confirmed unauthorised access, use, disclosure, modification, destruction, or denial of service of GIWAHS systems or data.
• Personal Data Breach — a Security Incident leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Personal Data.

12.2 Severity matrix

12.3 Phases

1. Identification — alert/report received; on-call engineer paged for SEV-1/2; incident ticket opened.
2. Containment — limit blast radius (revoke credentials, block IPs, take affected services offline, rotate secrets); preserve forensic state.
3. Eradication — remove cause (patch, configuration, code fix, account deactivation).
4. Recovery — restore service from clean state; monitor for re-occurrence.
5. Notification — internal stakeholders, Customers, regulators, affected individuals per Section 13.
6. Lessons learned — blameless post-incident review within 10 business days; corrective actions tracked to closure.

12.4 Forensics

• Audit logs preserved for at least 13 months (longer if a legal hold is in place).
• For SEV-1, write-protect relevant log stores within 1 hour of declaration.
• Where appropriate, engage external incident-response / forensics counsel.

13. Breach Notification

13.1 To Customers (Doc 29 §9)

• Within 72 hours of GIWAHS becoming aware of a Personal Data Breach affecting Customer Personal Data, by email to the security/privacy contact on file (or the account owner where none is registered).
• Notification includes nature, categories and approximate number affected, likely consequences, mitigation, and contact point.

13.2 To supervisory authorities

• Customer, as Controller, is responsible for notifying supervisory authorities under Article 33 GDPR / UK GDPR.
• Where GIWAHS is itself Controller (e.g., for its own employees), GIWAHS will notify within 72 hours.

13.3 To data subjects

• Where required under Article 34 GDPR / UK GDPR, US state breach notification statutes, the NZ Privacy Act 2020 (NotifyUs framework), or the AU NDB scheme — GIWAHS will support Customer in notifying affected data subjects, or notify directly where GIWAHS is Controller.

13.4 To NZ Privacy Commissioner

• For incidents meeting the “notifiable privacy breach” threshold under the NZ Privacy Act 2020, GIWAHS will notify the Office of the Privacy Commissioner via the NotifyUs portal as soon as practicable.

13.5 To OAIC (Australia)

• For incidents meeting the Notifiable Data Breach scheme threshold under APP 11A, GIWAHS will assist Customer in notifying the OAIC and affected individuals as soon as practicable and within statutory timeframes.

13.6 To US Attorneys General / consumers

• For US-state-law-triggering incidents, notifications follow the state-specific timing and content rules (typically within 30–60 days).

13.7 No admission of fault

• A notification is operational and is not an admission of fault or liability.

14. Physical Security

GIWAHS is a remote-first operation. There is no GIWAHS-owned data centre; physical security of production systems is delegated to: - Supabase / AWS for primary database and edge functions; - Stripe for payment infrastructure; - Cloudflare for edge POPs; - Google Workspace for corporate identity/email/storage. Each is reviewed for SOC 2 Type II / ISO 27001 / equivalent independent assurance.

Personnel devices: full-disk encryption; screen-lock; managed via MDM where deployed; secure-by-default configuration.

15. Vulnerability Disclosure

• Researchers may report findings to security@giwahs.com.
• We aim to acknowledge within 2 business days, triage within 5 business days, and remediate per CVSS severity (critical ≤ 7 days, high ≤ 30 days, medium ≤ 90 days).
• We commit to good-faith safe harbour: researchers acting in good faith under our policy will not be subject to legal action by GIWAHS.

16. Compliance Roadmap

• Year 1: this Policy in force; documented runbooks; vendor SOC 2 reliance.
• Year 1–2 target: SOC 2 Type I, then Type II audit.
• Year 2–3 target: ISO 27001 certification.
• Continuous: GDPR/UK GDPR/NZ Privacy Act/AU Privacy Act/CCPA compliance reviews; counsel-led updates as laws evolve.

17. Review & Change Control

• This Policy is reviewed at least annually and after any SEV-1/2 incident.
• Changes are logged in /app/memory/founder_vault/00_Approved_Decisions_Log.md.
• Material changes affecting Customers are communicated per Doc 29 §6.3 / Doc 25 §18.3.

18. Contact

• Security incidents (24/7 best-effort): security@giwahs.com
• Privacy / data protection: privacy@giwahs.com
• Customer queries: support@giwahs.com

End of Document 30.