# MySafeSigns — CAIQ-Lite v4 (Pre-filled)

**Version:** 1.0
**Date:** 2026-04-28
**Owner:** SymbioTeK Pty Ltd (ACN 694 230 334)
**Format:** Cloud Security Alliance CAIQ v4 Lite — Yes/No/N/A answers with cited evidence.

> **Honesty pledge:** every "Yes" cites a section of `Security.md` or our [Security & Architecture White Paper](/security/MySafeSigns-Security-Whitepaper-v1.md). Every "No" includes a compensating-control note. Procurement teams who audit any single answer will find the supporting evidence; we have not fudged answers.
>
> **Format note:** this is a Markdown rendering of the CAIQ-Lite v4 questions. The official CSA spreadsheet (.xlsx) is gated behind CSA STAR registration; if your procurement team requires the spreadsheet form, we will copy these answers into it on request — email <symbiotek@symbio-tek.com>.

---

## A&A — Audit & Assurance

| ID | Question | A | Notes |
|---|---|---|---|
| A&A-01 | Are independent audit and assurance assessments conducted at least annually? | No | Compensating control: this self-assessment, the [Security White Paper](/security/MySafeSigns-Security-Whitepaper-v1.md), and the [Essential Eight Self-Assessment](/security/Essential-Eight-Self-Assessment-v1.md) constitute internal audit evidence. SOC 2 Type I is on the roadmap (see White Paper §10.2). |
| A&A-02 | Are independent audit and assurance assessments performed according to risk-based plans and policies? | No | Same compensating control as A&A-01. We follow industry good-practice without a formal risk-based plan at v1. |
| A&A-03 | Is a remediation plan developed in response to review findings? | Yes | Findings from this self-assessment and from the planned 2026 pen test are tracked in `Launch-Checklist.md` and the GitHub Issues tracker. |
| A&A-04 | Are reviews of internal audit findings done in accordance with the audit plan? | N/A | No formal internal audit programme exists at v1. |
| A&A-05 | Are external audit certifications (e.g. SOC 2, ISO 27001) maintained? | No | Compensating control: our sub-processors (Supabase, Anthropic, Stripe, Netlify) all maintain SOC 2 Type II. Inherited compliance is documented in the [sub-processor list](/security/sub-processors.html). |

## AIS — Application & Interface Security

| ID | Question | A | Notes |
|---|---|---|---|
| AIS-01 | Is application security baselines documented? | Yes | `Security.md` §2 enumerates each control with file references. |
| AIS-02 | Are application security vulnerabilities remediated based on a documented process? | Yes | Issues are filed in the GitHub repository; security-classified issues are prioritised over feature work. |
| AIS-03 | Is the SDLC documented and followed? | Yes | The repository follows a `main` → `production` branch model with PR review (currently founder self-review; this is documented as a known limitation in the White Paper §10.1). |
| AIS-04 | Are inputs from untrusted sources validated? | Yes | Stripe webhook signature verification (`Security.md` §2.1) and Supabase RLS (`Security.md` §2.5) are the two highest-risk inputs; both are validated server-side. |
| AIS-05 | Are application security tests performed throughout the SDLC? | Partial | Manual security review is performed before each release. Automated SAST/DAST is not in place at v1; documented as a known limitation in the White Paper §10.1. |

## BCR — Business Continuity Management & Operational Resilience

| ID | Question | A | Notes |
|---|---|---|---|
| BCR-01 | Are documented business continuity and disaster recovery (BC/DR) plans in place? | Partial | At v1: backups handled by Supabase platform (point-in-time recovery enabled in production); the application is a static site re-deployable from Git in minutes. A formal BC/DR plan is on the roadmap. |
| BCR-02 | Is BC/DR tested at least annually? | No | Compensating control: as a static-site SaaS with stateless edge functions, recovery is exercised implicitly on every deploy. Formal annual testing scheduled for Q4 2026. |
| BCR-03 | Are backups maintained for production data? | Yes | Supabase managed backups (point-in-time recovery, 7 days at v1). User-controlled local backups via the App's Settings → Backup feature, optionally AES-256-GCM encrypted. |
| BCR-04 | Are backups tested for recoverability? | Partial | Application restore from Git is tested implicitly on every deploy. Database restore from Supabase backup has not been formally rehearsed at v1; scheduled for Q3 2026. |

## CCC — Change Control & Configuration Management

| ID | Question | A | Notes |
|---|---|---|---|
| CCC-01 | Are changes to production controlled through a documented change management process? | Yes | All code changes go through GitHub PRs to the `production` branch which auto-deploys via Netlify. PR template includes a test plan. |
| CCC-02 | Is the production environment separated from development and test environments? | Yes | Production is the `production` branch on Netlify (mysafesigns.symbio-tek.com). Dev/staging is `main` on GitHub Pages. Stripe live and test modes are completely separate. |
| CCC-03 | Are configuration management baselines defined and maintained? | Yes | `netlify.toml`, `supabase/config.toml`, and `supabase/migrations/` are version-controlled. Edge function secrets are managed in Supabase's secret store. |
| CCC-04 | Are emergency changes documented after the fact? | Yes | Hotfix commits go through PR like normal changes. Emergency-only override is not currently used. |

## CEK — Cryptography, Encryption & Key Management

| ID | Question | A | Notes |
|---|---|---|---|
| CEK-01 | Are encryption controls documented? | Yes | White Paper §6. |
| CEK-02 | Is data encrypted at rest? | Partial | Yes for Supabase database (AES-256, AWS-managed) and user-encrypted backups (AES-256-GCM). No for browser IndexedDB (relies on device-level disk encryption — explicitly disclosed in White Paper §10). |
| CEK-03 | Is data encrypted in transit? | Yes | TLS 1.2+ enforced. HSTS preload-eligible (max-age 2 years). |
| CEK-04 | Are cryptographic keys managed in accordance with documented procedures? | Yes | TLS keys: managed by Netlify and Supabase. Stripe webhook signing secret: rotated via Stripe dashboard. AES-256-GCM backup keys: derived per-export from user passphrase via PBKDF2-SHA256 (250,000 iterations). |
| CEK-05 | Are user-controlled encryption keys (BYOK) supported? | No | Compensating control: backup encryption uses a user-controlled passphrase rather than a SymbioTeK-held key. There is no SymbioTeK access path to encrypted backups. |

## DSP — Data Security & Privacy

| ID | Question | A | Notes |
|---|---|---|---|
| DSP-01 | Are data classifications documented? | Yes | White Paper §3 (Data flow per data class) classifies each data type by retention location. |
| DSP-02 | Is data labelled in accordance with classification? | N/A | The data model is small and uniformly classified at the application boundary. Per-record labels would add no signal. |
| DSP-03 | Is sensitive data protected with appropriate controls? | Yes | RLS forced on all user-data tables; webhook signature verification on the billing path; AES-256-GCM available for backups. |
| DSP-04 | Are data retention periods defined? | Yes | Privacy Policy §7 documents retention periods. Pseudonymised credit transaction log is retained 7 years to meet Australian record-keeping obligations. |
| DSP-05 | Are data deletion procedures defined? | Yes | Deletion-on-request is honoured within 30 days. DPA template Clause 10.2 documents the deletion-on-termination process. |
| DSP-06 | Are data subject access rights honoured? | Yes | Privacy Policy §8 (APP 12, 13). |
| DSP-07 | Is cross-border data transfer documented? | Yes | Privacy Policy §6 and DPA Annex B name every cross-border recipient. |

## DCS — Data Centre Security

| ID | Question | A | Notes |
|---|---|---|---|
| DCS-01 | Are data centre physical security controls in place? | Yes (inherited) | Inherited from AWS (Supabase) and from Stripe's PCI-DSS L1 facilities. SymbioTeK does not operate any data centre. |
| DCS-02 | Are data centre environmental controls in place? | Yes (inherited) | Inherited from AWS, per their SOC 2 Type II reports. |

## GRC — Governance, Risk & Compliance

| ID | Question | A | Notes |
|---|---|---|---|
| GRC-01 | Is an information security policy documented? | Yes | `Security.md` and the White Paper together constitute SymbioTeK's information security policy. |
| GRC-02 | Is a risk management process in place? | Partial | Risks are identified and documented in `Security.md` §4 (residual risks) and the White Paper §10.1. A formal risk register with quantitative scoring is on the roadmap. |
| GRC-03 | Are roles and responsibilities for security defined? | Yes | At v1, the founder holds all security roles. This is a documented limitation; succession planning is on the roadmap. |
| GRC-04 | Is a code of conduct in place? | N/A | Single-founder company at v1. |

## HRS — Human Resources

| ID | Question | A | Notes |
|---|---|---|---|
| HRS-01 | Are background checks performed on personnel with access to customer data? | N/A | Single-founder company at v1. The founder has no criminal record. Background check evidence available on request. |
| HRS-02 | Are personnel trained on security responsibilities? | Yes | Founder maintains security knowledge through ongoing self-study; evidence available on request. |
| HRS-03 | Is access removed when personnel leave? | N/A | Single-founder company at v1. Procedure documented in `Security.md` for future contractors. |
| HRS-04 | Are confidentiality agreements in place? | Yes | Required of any future contractors per the standard contractor template. |

## IAM — Identity & Access Management

| ID | Question | A | Notes |
|---|---|---|---|
| IAM-01 | Are user access rights reviewed periodically? | Partial | At v1, the only privileged identities are the founder's accounts on Supabase, Stripe, GitHub, and Netlify. End-user RLS access is constrained automatically per row. Quarterly review of operator access is scheduled. |
| IAM-02 | Is multi-factor authentication required for privileged access? | Yes | TOTP MFA enforced on Supabase, Stripe, GitHub, and Netlify operator accounts. |
| IAM-03 | Are unique user accounts assigned to each individual? | Yes | All operator access is per-individual; no shared accounts. |
| IAM-04 | Are passwords stored using one-way hashing? | Yes | Supabase Auth uses bcrypt (or equivalent) for password storage. |
| IAM-05 | Is least privilege enforced? | Yes | RLS enforces row-level least privilege. The Supabase service-role key is restricted to Edge Functions and never exposed to the browser. |
| IAM-06 | Is single sign-on supported? | No | Compensating control: Supabase Auth supports OAuth providers (Google, GitHub) which can be enabled per-customer. SAML/SSO is on the roadmap. |
| IAM-07 | Are API keys / tokens rotated periodically? | Partial | Stripe webhook signing secret rotation procedure documented; rotation schedule is on the roadmap. Supabase service role key has not been rotated; is environment-managed. |

## IPY — Interoperability & Portability

| ID | Question | A | Notes |
|---|---|---|---|
| IPY-01 | Is data export to a portable format supported? | Yes | Settings → Backup → Export Full Backup produces a JSON file (or AES-256-GCM encrypted JSON). User retains full data portability. |
| IPY-02 | Are open standards used for data formats? | Yes | JSON for backups; CSV for reports. No proprietary formats. |
| IPY-03 | Is import / migration support provided? | Yes | Settings → Backup → Import. |

## IVS — Infrastructure & Virtualisation Security

| ID | Question | A | Notes |
|---|---|---|---|
| IVS-01 | Are infrastructure components hardened? | Yes (inherited) | Inherited from AWS (Supabase), Stripe, Netlify per their respective SOC 2 reports. SymbioTeK operates no servers directly. |
| IVS-02 | Is network traffic logged and monitored? | Partial | Supabase, Netlify and Cloudflare retain access logs per their default policies. SymbioTeK does not currently centralise log analysis; documented in White Paper §10.1. |

## LOG — Logging & Monitoring

| ID | Question | A | Notes |
|---|---|---|---|
| LOG-01 | Are security-relevant events logged? | Partial | Supabase Edge Function logs retain authentication events and webhook delivery records. Application-level audit logs (per-user activity) are not implemented at v1. |
| LOG-02 | Are log entries protected from unauthorised access and modification? | Yes (inherited) | Logs are held within Supabase / Netlify and inherit those providers' integrity controls. |
| LOG-03 | Are logs retained according to a documented schedule? | Partial | Provider defaults apply (Supabase: 7 days for free tier, longer for paid). Customer-specific retention can be negotiated. |
| LOG-04 | Are alerts configured for security-relevant events? | No | Compensating control: Stripe and Supabase send email alerts on persistent webhook failures and project anomalies. Centralised alerting (Sentry / Logflare) is on the roadmap, documented in `Launch-Checklist.md` §G. |

## SEF — Security Incident Management

| ID | Question | A | Notes |
|---|---|---|---|
| SEF-01 | Is an incident response plan documented? | Yes | White Paper §9. |
| SEF-02 | Are response targets defined? | Yes | White Paper §9.2 (1 business day acknowledge, 5 days triage, 72-hour customer notification on confirmed incident). |
| SEF-03 | Is a public disclosure mechanism in place? | Yes | <https://mysafesigns.symbio-tek.com/.well-known/security.txt> (RFC 9116). |
| SEF-04 | Are post-incident reviews performed? | Yes | White Paper §9.3 commits to a public write-up for material incidents. |

## STA — Supply Chain Management, Transparency, Accountability

| ID | Question | A | Notes |
|---|---|---|---|
| STA-01 | Is a sub-processor list maintained? | Yes | <https://mysafesigns.symbio-tek.com/security/sub-processors.html>. |
| STA-02 | Are customers notified of sub-processor changes? | Yes | DPA Clause 7.4: 30 days' written notice with right to object. |
| STA-03 | Are sub-processors required to provide equivalent protections? | Yes | DPA Clause 7.4. |
| STA-04 | Is the supply chain reviewed for security risks? | Partial | Sub-processors selected partly on the basis of their published security posture (SOC 2 / PCI-DSS). Annual review of sub-processor security is on the roadmap. |

## TVM — Threat & Vulnerability Management

| ID | Question | A | Notes |
|---|---|---|---|
| TVM-01 | Are vulnerabilities tracked and remediated based on severity? | Yes | GitHub Dependabot is enabled on the repository; security-classified issues are prioritised. |
| TVM-02 | Are penetration tests performed regularly? | No (planned) | Compensating control: this self-assessment, the Essential Eight self-assessment, and the platform-level pen tests of our sub-processors. CREST-AU pen test scheduled for Q3 2026 (White Paper §10.2). |
| TVM-03 | Are vulnerability scans performed regularly? | Partial | GitHub Dependabot for Node/JS dependencies. Web-app scanning (e.g. OWASP ZAP) is not yet automated. |
| TVM-04 | Is a patch management process in place? | Partial | Dependencies are updated via PR. Operating systems are managed by sub-processors (we operate no servers). |

## UEM — Universal Endpoint Management

| ID | Question | A | Notes |
|---|---|---|---|
| UEM-01 | Are endpoint security controls applied to operator devices? | Yes | Founder's operator devices have FileVault (macOS) full-disk encryption, automatic OS updates, and a password-protected screen lock. |
| UEM-02 | Are mobile device management controls in place? | Partial | Single-founder company. Apple ID with Find My / device wipe enabled on operator devices. Formal MDM is not in place at v1. |

---

## Summary

| Domain | Yes | No | Partial | N/A |
|---|---|---|---|---|
| A&A | 1 | 2 | 0 | 2 |
| AIS | 4 | 0 | 1 | 0 |
| BCR | 1 | 1 | 2 | 0 |
| CCC | 4 | 0 | 0 | 0 |
| CEK | 3 | 1 | 1 | 0 |
| DSP | 6 | 0 | 0 | 1 |
| DCS | 2 | 0 | 0 | 0 |
| GRC | 1 | 0 | 1 | 2 |
| HRS | 1 | 0 | 0 | 3 |
| IAM | 4 | 1 | 2 | 0 |
| IPY | 3 | 0 | 0 | 0 |
| IVS | 1 | 0 | 1 | 0 |
| LOG | 1 | 1 | 2 | 0 |
| SEF | 4 | 0 | 0 | 0 |
| STA | 3 | 0 | 1 | 0 |
| TVM | 1 | 1 | 2 | 0 |
| UEM | 1 | 0 | 1 | 0 |

The "No" responses cluster around: independent third-party audit (A&A-01, A&A-02, A&A-05), formal BC/DR testing (BCR-02), BYOK (CEK-05 — addressed by passphrase-derived backup keys), SSO at v1 (IAM-06), centralised alerting (LOG-04), and pen testing (TVM-02 — scheduled). Every "No" is documented in the [Security & Architecture White Paper](/security/MySafeSigns-Security-Whitepaper-v1.md) §10.1 (Known limitations) and has a compensating-control note above.

For any procurement-team question not answered here, please email <symbiotek@symbio-tek.com> and we will respond within 5 business days.

---

*Document version 1.0. Re-published with each material change to controls or sub-processors. The current version of this questionnaire is at <https://mysafesigns.symbio-tek.com/security/MySafeSigns-CAIQ-Lite-v1.md>.*