| Document owner | Security Lead, Margineer |
| Version | 1.0 (draft for review) |
| Status | Pre-launch — for partner review and internal implementation |
| Applies to | Margineer web application and all systems that process customer data |
| Jurisdictions | New Zealand and Australia |
| Review cycle | Every 12 months, or after any material change or significant incident |
1. Purpose and scope
Margineer is an AI-powered web application, built by accountants, that turns a manufacturer's financial and operating data into plain-English insight. Customers across New Zealand and Australia entrust Margineer with sensitive business information. This policy defines how that information is classified, retained, protected, monitored and recovered, and how Margineer responds when something goes wrong.
It covers five areas: data retention, data-breach security and response, audit logging, incident logging and response, and disaster recovery and business continuity.
2. What Margineer holds — data classification
Every control in this policy is sized against the sensitivity of the data it protects. Margineer classifies data into four tiers.
| Tier | Examples | Handling standard |
|---|---|---|
| Confidential — business financials | Revenue, margins, product costs, pricing, inventory, payroll totals, cash-flow figures, uploaded CSV/Excel, Xero extracts | Encrypted at rest and in transit; access strictly least-privilege; tenant-isolated; access logged |
| Personal information (PII) | User and customer account details — name, email, business, contact | Governed by NZ Privacy Act 2020 and AU Privacy Act 1988 (APPs); minimised and access-controlled |
| Secrets & credentials | OAuth tokens (Xero), API keys, password hashes | Never stored in plaintext; held in a secrets manager; never written to logs |
| Operational / system | Audit logs, application logs, metrics | Integrity-protected; access-restricted; retained per the schedule in Section 3 |
Business financial data is treated as the highest-value asset: a breach here is commercially damaging to the customer, even where little personal information is involved.
3. Data retention
Margineer follows the principle of data minimisation: it collects only what the product needs and keeps it only as long as there is a clear purpose. The schedule below sets default retention periods. Periods marked (confirm) should be validated with the company's accountant and privacy counsel before launch.
| Data class | Retention | Then |
|---|---|---|
| Uploaded financial data & Xero extracts | Life of subscription | Secure deletion 90 days after cancellation (export window) |
| Derived insights & monthly reports | Life of subscription | Deleted with the source data |
| Account & PII | Life of account | Deleted or anonymised 90 days after closure |
| Billing & tax records | 7 years (confirm) | Retained to meet NZ/AU record-keeping rules, then deleted |
| Audit logs | 12 months minimum | Archived or securely deleted |
| Application / system logs | 90 days | Rotated and deleted |
| Database backups | 35-day rolling window | Oldest backups rotated out automatically |
| Secrets / OAuth tokens | While connection is active | Revoked and deleted on disconnect |
| Support communications | Life of account + 24 months | Deleted |
Deletion and offboarding
- Customer-initiated deletion. A customer can request deletion of their data; Margineer confirms and completes secure deletion within a defined window.
- Offboarding. On cancellation the customer gets an export window (default 90 days) to retrieve their data, after which it is securely deleted from primary systems.
- Backups. Deletion propagates to backups as they rotate out of the 35-day window; deleted data does not persist indefinitely in backup storage.
- Privacy rights. Under the NZ Privacy Act 2020 and the Australian Privacy Principles, individuals may request access to and correction of their personal information; Margineer honours these requests within statutory timeframes.
4. Data-breach security and response
Preventive controls
- Encryption in transit (TLS 1.2 or higher) and at rest for all customer data and backups.
- Least-privilege access; multi-factor authentication required on all administrative and production access.
- Strict tenant isolation — no customer can access another customer's data.
- Secrets held in a managed secrets store; no credentials in code, config or logs.
- Input validation, dependency and patch management, and hardened cloud configuration.
- Regular access reviews and removal of access on role change or departure.
Response process
When a breach is suspected, Margineer follows a defined sequence, with a single accountable owner:
| Step | What happens |
|---|---|
| 1. Detect & record | Log the event; open an incident record (Section 6) |
| 2. Triage & assess severity | Confirm scope; classify severity; determine data and individuals affected |
| 3. Contain | Stop the exposure — revoke access, isolate systems, rotate credentials |
| 4. Eradicate & recover | Remove the cause; restore clean service (Section 7) |
| 5. Notify | Assess notification obligations (below) and notify regulators/customers as required |
| 6. Review | Post-incident review and tracked remediation |
Notification obligations
New Zealand — Privacy Act 2020. If a privacy breach is likely to cause serious harm (a 'notifiable privacy breach'), Margineer must notify the Office of the Privacy Commissioner as soon as practicable after becoming aware of it, and notify affected individuals (or give public notice if individual notice is not reasonably practicable). Reporting is done via the Commissioner's NotifyUs tool. Failing to notify a serious breach is an offence carrying a fine of up to NZ$10,000.
Australia — Notifiable Data Breaches (NDB) scheme. Where an 'eligible data breach' is likely to result in serious harm, an entity covered by the scheme must notify the OAIC and affected individuals. An organisation generally has up to 30 days to assess whether a breach is likely to result in serious harm. The NDB scheme applies to APP entities (generally those with annual turnover above A$3M, and others in specific categories); Margineer adopts these obligations as a baseline standard and will confirm applicability as it grows.
Margineer keeps a record of every breach and its assessment, whether or not the threshold to notify is met. As an AI-powered product, Margineer also notes the 2024 Australian reforms introducing transparency obligations around automated decision-making, and will keep its privacy disclosures current.
5. Audit logs
Audit logs record who did what, to what, when and from where, so security-relevant activity can be investigated and demonstrated.
What is logged
- Authentication events — sign-in success and failure, MFA challenges.
- Authorisation changes — role, permission and access grants or removals.
- Access to confidential financial records, and all data exports or downloads.
- Administrative actions and configuration changes.
- Data deletion and retention actions.
How logs are protected
- Integrity. Append-only and tamper-evident; timestamped in UTC against a synced clock.
- No sensitive payloads. Logs record identifiers and actions, never secrets or full PII/financial content.
- Access. Restricted to authorised staff, itself audited, and reviewed on a defined cadence.
- Retention. Held for at least 12 months (see Section 3) to support investigation.
6. Incident logging and response
Audit logs are the routine record of security events. An incident log is the record of a specific incident being worked. Every incident — outage, suspected breach, data-integrity issue — gets its own record.
Every incident record captures
- Incident ID and timestamps: detected, contained, resolved.
- Severity, systems affected, and data / individuals affected.
- Actions taken, root cause, and follow-up remediation items.
Severity levels
| Level | Definition | Target response |
|---|---|---|
| SEV1 — Critical | Confirmed data breach or full service outage | Immediate; contain within 1 hour; owner + leadership engaged |
| SEV2 — High | Suspected breach, auth failure, or partial outage | Within 2 hours |
| SEV3 — Medium | Degraded service or single-customer impact | Within 1 business day |
| SEV4 — Low | Minor issue, no data risk | Next business day |
Every incident feeds a post-incident review and a tracked remediation list. Incident records support the breach-notification decisions in Section 4.
7. Disaster recovery and business continuity
Margineer sets recovery targets per system, backs data up securely, and — critically — tests that it can actually restore. An untested backup is not a backup.
Recovery targets
| System | RPO (max data loss) | RTO (max downtime) |
|---|---|---|
| Production database (customer data) | ≤ 1 hour (point-in-time recovery) | ≤ 4 hours |
| File storage (uploads, exports) | ≤ 24 hours | ≤ 8 hours |
| Application service | n/a (stateless — redeploy) | ≤ 4 hours |
Backups and testing
- Automated, encrypted backups on a defined schedule, held in a geographically separate location.
- Restore procedures documented and tested on a quarterly cadence, with results recorded.
Scenarios covered
Cloud region outage, data corruption, ransomware, accidental deletion, provider failure, and encryption-key loss.
Communications
A defined plan for keeping customers informed during an outage — status updates, expected restoration, and follow-up.
8. Roles, responsibilities and review
- Security Lead. Owns this policy, the incident process, and the review cadence; single accountable owner during an incident.
- All staff. Follow least-privilege and reporting practices; report suspected incidents immediately.
- Review. This policy is reviewed at least annually, and after any material change or significant incident.