Risk Management Policy & Register
SyncMate — WYHEN Pty Ltd (ABN 57 688 078 999) Version 1.0 · Effective 31 August 2026 · Owner: Founder/Technical Operator · Review: quarterly
1. Purpose
To identify, score, treat and monitor risks to the confidentiality, integrity and availability of customer data and the SyncMate service.
2. Scoring
Each risk is scored Likelihood (1–5) × Impact (1–5) = 1–25.
Likelihood: 1 Rare (not expected in 5 years) · 2 Unlikely (possible in 5 years) · 3 Possible (once in 1–2 years) · 4 Likely (once a year) · 5 Almost certain (multiple times a year).
Impact is assessed as the highest of: confidentiality (exposure of customer data), integrity (incorrect financial data reaching a customer's ledger), availability (service downtime), regulatory (notifiable breach or Privacy Act exposure), and client trust (loss of a customer relationship). 1 Negligible · 2 Minor · 3 Moderate · 4 Major · 5 Severe.
3. Treatment thresholds
| Score | Rating | Required action |
|---|---|---|
| 15–25 | High | Documented treatment plan with named owner and due date; reviewed monthly until reduced |
| 8–14 | Medium | Monitored and reviewed quarterly; treatment where cost-effective |
| 1–7 | Low | Accepted with a documented rationale and an expiry date not exceeding 12 months |
Treatment options: mitigate (add or strengthen a control), transfer (contract or insurance), avoid (stop the activity), accept (record with rationale and expiry). Every acceptance has an expiry date and is re-assessed at expiry — no risk is accepted indefinitely.
4. Review cadence and triggers
The register is reviewed quarterly. It is also reviewed immediately on any of the following trigger events:
- Onboarding or changing a subprocessor.
- A material architecture change, particularly to authentication, tenant isolation or file handling.
- Any security incident or near-miss.
- A relevant regulatory change (Privacy Act reform, NDB guidance, GDPR/UK developments).
- A penetration test or vulnerability assessment producing High or Critical findings.
- Onboarding an enterprise customer with a materially different risk profile.
5. Supplier and subprocessor risk
Before any subprocessor is used, it is assessed on: independent certification (SOC 2, ISO 27001), data residency, contractual data-protection terms (including AI no-training commitments), security incident history, financial viability, and exit difficulty. The assessment is recorded and re-reviewed annually. Customers are notified in advance of subprocessor additions or changes with a right to object.
6. Tooling
The register is maintained in the compliance-automation platform used for the ISO 27001 programme, with a version-controlled copy held with the security documentation set. Technical risk inputs come from automated dependency and code scanning, database access-policy linting, penetration test findings and the threat intelligence process (A7).
7. Current risk register (initial)
| ID | Risk | L | I | Score | Rating | Treatment | Owner | Review |
|---|---|---|---|---|---|---|---|---|
| R1 | Cross-tenant data exposure through a flaw in access policies | 2 | 5 | 10 | Medium | Database-enforced RLS on every table; mandatory review checklist; policy linting on every migration; penetration test scope includes isolation | Founder | Quarterly |
| R2 | Key-person dependency — single principal | 3 | 4 | 12 | Medium | Infrastructure-as-code in version control; credential escrow with emergency access to a named trusted contact; documented runbook in the BCP/DR | Founder | Quarterly |
| R3 | Credential compromise of an administrative account | 2 | 5 | 10 | Medium | Xero-only authentication with provider-enforced two-step verification; no password credentials held; audit logging of administrative actions; immediate rotation procedure | Founder | Quarterly |
| R4 | Subprocessor outage (hosting, AI, Xero) degrading service | 3 | 3 | 9 | Medium | Providers with redundant infrastructure; extraction queue retries; documented recovery scenarios in the BCP/DR; customer communication thresholds | Founder | Quarterly |
| R5 | Malicious file uploaded and later opened by a user | 2 | 3 | 6 | Low | Upload type/size restriction; isolated storage; in-browser rendering, never execution; no public URLs. Accepted; expiry 31 Aug 2027; signature scanning to be reconsidered at review | Founder | Annually |
| R6 | Incorrect extraction reaching a customer's ledger | 3 | 3 | 9 | Medium | Mandatory human review before publishing; reconciliation and balancing checks; audit trail of every change | Founder | Quarterly |
| R7 | Absence of ISO 27001 / SOC 2 limiting enterprise sales | 4 | 2 | 8 | Medium | ISO 27001 readiness programme with a compliance-automation platform; documented control set in the interim | Founder | Quarterly |
| R8 | Data loss from database or storage failure | 2 | 5 | 10 | Medium | Daily automated backups with point-in-time recovery; annual documented restore test; RPO 24h / RTO 1 business day | Founder | Quarterly |
| R9 | Vulnerable third-party dependency | 3 | 3 | 9 | Medium | Automated dependency scanning on every change; severity-based remediation SLA (A6); weekly advisory triage | Founder | Quarterly |
| R10 | Delayed detection of an incident (no centralised SIEM) | 3 | 3 | 9 | Medium | Platform logging retained; in-product audit trail; error alerting to the operator. Centralised SIEM available if required by an engagement; accepted with expiry 31 Aug 2027 | Founder | Annually |