Information Security Policy

Owner: Luke Ferguson trading as Mealward Security Officer (interim: founder) Audience: all Luke Ferguson trading as Mealward personnel and contractors with access to production systems or Customer Data Document type: internal policy. Public summary may be shared with enterprise customers under NDA. Version: 1.0 (DRAFT - lawyer review required) Review cadence: at least annually, or on material change

1. Purpose and scope

1.1 This Information Security Policy ("Policy") sets out the security commitments Luke Ferguson trading as Mealward makes to its customers and the controls all Luke Ferguson trading as Mealward personnel must follow.

1.2 It applies to all Luke Ferguson trading as Mealward systems, all personnel (employees, contractors, and authorised third parties), and all Customer Data processed by the Service.

1.3 The Policy is aligned to the Australian Cyber Security Centre (ACSC) Essential Eight. Luke Ferguson trading as Mealward's target is Maturity Level 1 (ML1) at launch and Maturity Level 2 (ML2) within 12 months of onboarding the first enterprise customer. Progress against the Essential Eight is tracked in the security register reviewed quarterly by the Security Officer.

1.4 This Policy supports Luke Ferguson trading as Mealward's obligations under the Privacy Act 1988 (Cth), particularly APP 11 (security of personal information), and the technical and organisational measures (TOMs) committed to in DPA Schedule 2.

2. Roles and responsibilities

Security Officer owns this Policy, the security register, vulnerability triage, and the incident response programme. Reports to the founder/CEO.
Privacy Officer owns the Privacy Policy, DPA, individual rights requests, and Notifiable Data Breach assessment. May be the same person as the Security Officer at start-up scale.
Engineering leads own implementation of security controls in code, infrastructure, and CI/CD.
Every person with access is responsible for following this Policy and reporting suspected security or privacy issues to {{SECURITY_EMAIL}} immediately.

3. Data classification

Class	Definition	Examples	Default handling
Public	Approved for general release	Marketing site copy, public docs	No special controls
Internal	For Luke Ferguson trading as Mealward use only	Internal docs, draft features	Access limited to employees and contractors
Confidential	Operational data, customer correspondence	Support tickets, billing data	MFA, least privilege, audit logging
Restricted	Customer Data, including resident Health Information	Resident records, audit logs	All "Confidential" controls + RLS, named-access only, encryption-at-rest, no copies on personal devices

Restricted data may never be:

copied to personal email, personal cloud storage, or personal devices;
shared in unsecured chat tools or screenshots;
used for development or testing without de-identification.

4. Access control

4.1 Identity provider. All Luke Ferguson trading as Mealward staff use Google Workspace SSO as the canonical identity. Service-specific accounts are provisioned via SSO where supported.

4.2 MFA. MFA is mandatory for all accounts that can access Confidential or Restricted data, including: Google Workspace, GitHub, Vercel, Supabase, Sentry, Upstash, AWS, Stripe, the password manager, and any other production-relevant SaaS.

4.3 Least privilege. Access is granted on a least-privilege basis. Engineers do not have standing write access to the production database; access is requested just-in-time with reason and time bound, and is logged.

4.4 Quarterly access review. The Security Officer runs a quarterly access review across all SaaS systems, comparing actual access to the access register, and revokes any orphaned or excessive privileges. The review is recorded with date, reviewer, and findings.

4.5 Joiner / mover / leaver.

Joiner: access provisioned only on signed offer letter and acknowledged Acceptable Use Policy; specific systems granted on need.
Mover: access reviewed within 5 business days of role change.
Leaver: all access revoked within 24 hours of termination of engagement; production credentials rotated within 24 hours; physical assets returned within 7 days.

4.6 Privileged action logging. Privileged actions (production database access, role changes, secret access) are logged centrally with at least 90 days of retention.

5. Authentication

Passwords for personal accounts must be unique per service, generated and stored in a managed password manager (1Password or equivalent).
Minimum password length 14 characters where the service does not enforce a stronger policy.
Hardware-backed MFA (WebAuthn / YubiKey) preferred for production-critical systems; TOTP acceptable; SMS not acceptable for any production system.
For Customer Authorised Users, the Service supports SSO (SAML / OIDC) on enterprise plans and offers MFA on all plans.

6. Endpoint security

Company devices are encrypted at the disk level (FileVault / BitLocker).
OS auto-update is enabled; major-version upgrades within 30 days of GA.
Endpoint detection and response (EDR) tooling is installed once headcount makes it cost-effective; in the interim, baseline OS security tooling is enforced via MDM (Apple Business Manager / Microsoft Intune).
Removable media is discouraged and never used to transfer Restricted data.

7. Network security

All in-transit traffic is TLS 1.2+ (HSTS preload on production domain).
The production database is not reachable from the public internet; it is accessed via the application tier, with a tightly scoped admin path that requires MFA + short-lived session credentials.
A Web Application Firewall (Vercel + framework defaults + custom rules) enforces baseline OWASP protections and rate limits.
Inbound and outbound traffic from production is logged and retained for at least 90 days.

8. Cryptography

At rest: AES-256 for the database, object storage, and backups (provided by Supabase / AWS managed encryption).
In transit: TLS 1.2+ everywhere; mTLS where supported between internal services.
Secrets: stored in a managed secret store (Vercel encrypted env, Supabase secrets, or 1Password Secrets Automation). No secrets in source control. CI gate runs gitleaks on every PR.
Keys: managed by the underlying cloud provider with rotation policies (AWS KMS / Supabase). Customer-managed keys (CMK) considered for enterprise customers on request.

9. Application security

All authenticated routes require server-side authorisation checks; tenant isolation enforced via PostgreSQL Row-Level Security (RLS) keyed to the tenant ID claim from the auth provider. CI gate detects new tables without RLS.
Input validation on all API boundaries (Zod or equivalent).
Output encoding by default in the framework; explicit review for any dangerouslySetInnerHTML or equivalent.
CSRF protection on state-changing routes; CSP set with a tight allow-list and no unsafe-inline for scripts.
Dependency scanning via Dependabot weekly, with auto-PRs for non-major updates; high/critical advisories actioned within 7 days.
Static analysis: TypeScript strict mode + ESLint security rules in CI; merges blocked on failure.
Secret scanning enabled on the Git host; rejected pushes for known credential patterns.
Annual third-party penetration test target once we have onboarded the first enterprise customer.

10. Vulnerability management

10.1 The Security Officer maintains a vulnerability register listing each known issue, severity, owner, and target close date.

10.2 Triage targets:

Severity (CVSS or equivalent business assessment)	Target time to remediate or mitigate
Critical (>= 9.0)	7 days
High (7.0 - 8.9)	30 days
Medium (4.0 - 6.9)	90 days
Low (< 4.0)	next quarterly cycle

10.3 Where remediation is not possible within the target, a documented compensating control is recorded.

10.4 Responsible disclosure: external researchers may report vulnerabilities to {{SECURITY_EMAIL}} under a published responsible-disclosure programme. Luke Ferguson trading as Mealward commits to acknowledge within 5 business days and not pursue legal action against good-faith researchers.

11. Change management

Every production change ships through a reviewed pull request with at least one independent approver.
CI gates that must pass before merge: tests, type-check, lint, secret scan, dependency audit, RLS check.
Production deploys are automated; manual production access is logged and reviewed.
Database migrations follow the production migration runbook (docs/DEV-WORKFLOW.md): backwards-compatible migration, deploy code, run migration, verify, then code cleanup. Rollback plan documented before merge.
Emergency change process: a single-approver hotfix path is permitted for Sev 1 incidents, followed by a same-day post-merge review by a second engineer.

12. Backup and disaster recovery

Backups: nightly logical backups (pg_dump) of the production database, plus continuous WAL archiving. Backups encrypted with AES-256.
Retention: 90 days. After 90 days backups are cryptographically destroyed.
Restore drills: at least once per quarter the Security Officer or delegate restores the most recent backup into an isolated environment, confirms data integrity, and records the drill.
RPO 24 hours, RTO 8 hours for full Service restoration after a confirmed disaster.
A documented disaster recovery plan covers regional cloud outage, data corruption, ransomware, and supplier insolvency scenarios.

13. Logging and monitoring

Application logs centralised; PII fields tagged and access-controlled.
Audit logs (authentication, authorisation, privileged action, data export) retained for at least 7 years to support aged-care record-keeping.
Error monitoring via Sentry with PII scrubbing before send.
Alerts on authentication anomalies, privileged actions, SLO breaches, and security-relevant rule violations.
Status page at https://status.mealward.com is updated for any customer-impacting event.

14. Personnel security

Background checks for all staff with production access, where lawful: identity verification, right-to-work check, criminal record check via the National Police Check.
All staff sign a confidentiality agreement and Acceptable Use Policy.
Annual security and privacy awareness training, with completion tracked.
Specialist training (secure coding, incident handling) for engineering staff.

15. Vendor and sub-processor management

New vendors that will process Customer Data are assessed against this Policy before onboarding. The Security Officer signs off in writing.
Annual review of sub-processors' security reports (SOC 2, ISO 27001) where available.
Sub-processor changes are notified to enterprise customers under the DPA.
The current authoritative sub-processor list is in DPA Schedule 3.

16. Physical security

Luke Ferguson trading as Mealward operates a remote-first workforce; there is no on-premises infrastructure containing Customer Data.
Office or co-working spaces (if used) require physical access control; Restricted data is never printed in shared spaces.
All servers are managed cloud services; physical security is the responsibility of the underlying cloud provider.

17. Privacy by design

New features go through a lightweight Privacy Impact Assessment (PIA) before release where they introduce a new data category, new sub-processor, or change in retention.
The PIA register is reviewed by the Privacy Officer.
AI / ML features have a separate model-data flow review.

18. Incident management

18.1 Security and privacy incidents are managed under the Incident Response Runbook (docs/legal/INCIDENT-RESPONSE-RUNBOOK.md).

18.2 All staff must report suspected incidents to {{SECURITY_EMAIL}} or by paging the on-call within 1 hour of becoming aware.

18.3 A written post-incident review is produced for every Sev 1 incident; remediation actions are tracked to closure in the security register.

19. Essential Eight alignment

Mitigation	Current target (ML1 launch)	12-month target (ML2)
Application control	N/A on dev endpoints; locked-down managed laptops via MDM	EDR with allow-list policy on all production-access endpoints
Patch applications	Dependabot weekly; advisories actioned per clause 10.2	Auto-patching of all dev tooling; CI gate on outdated runtimes
Configure MS Office macros	Macros disabled by default in Workspace	Continued; reviewed annually
User application hardening	Browsers auto-updated; ad / tracker blockers on managed devices	Same; tracked in MDM compliance dashboard
Restrict administrative privileges	Quarterly access review; just-in-time prod access	Privileged Access Management workflow with auto-expiry
Patch operating systems	Auto-update on managed devices	MDM-enforced patch SLAs reported quarterly
Multi-factor authentication	Mandatory across all production-relevant SaaS	Hardware-backed MFA on production-critical systems
Regular backups	Nightly + WAL archive; quarterly restore drill	Same; plus annual cross-region restore drill

20. Policy exceptions

Any exception to this Policy must be requested in writing to the Security Officer with a business justification, expiry date, and compensating control. Exceptions are recorded in an exceptions register and reviewed quarterly.

21. Acknowledgement

All personnel acknowledge this Policy on joining and on each material update. The acknowledgement record is maintained by the Privacy Officer.

DRAFTING NOTES

ML1 -> ML2 in 12 months. Realistic for a focused team but tight. The hardest two are application control (needs EDR licensing) and PAM with auto-expiry. Budget about AUD 15-25k/yr for tooling.
Audit log 7-year retention (clause 13). Long, but matches aged-care provider record-keeping expectations and simplifies the Aged Care compliance mapping document. Storage cost is negligible at this data volume.
Background checks (clause 14). NPC is the lowest reasonable bar; some enterprise customers will require Working with Vulnerable People checks even though staff do not have direct contact with residents. Defensible to refuse, but signal willingness to do per-customer.
Penetration test cadence. Annual is the right cadence; do not overspend on twice-yearly until customer scale justifies it.
Privacy Officer / Security Officer separation. At start-up scale these roles will be combined. Once headcount is over 10, separate them.