SCOPE: everything in progressdocs/compliance/information-security-policy.md · build 40bb41bdb460

Information security policy (draft)

Lucent Axis, SCOPE. Draft 28 Oct 2026. Owner: Dan. Approved by: [Kyle, on return]. Review: yearly, or when the team or the systems change. Everyone with access to SCOPE's systems signs it on joining and every year (ORG-14). SOC 2 CC1.1, CC1.3, CC2.2, CC5.3, CC6.1, CC6.7, CC6.8, CC7.1; items ORG-09, TS-1, TS-7.

This is the umbrella. Its sections are short policies of their own; the longer ones sit beside it: change management, data classification and retention, BYOD and laptops, incident response, business continuity, joining and leaving, vendors, risk.

1. Scope

The SCOPE platform and every account, laptop and person that can reach it, as listed in the system inventory. Applies to staff and contractors alike.

2. Roles

Role Holder Responsible for
Security owner Kyle This policy set, the risk register, vendors, the auditor, the quarterly security review
Platform owner Dan Hosting, database, backups, access to the company accounts, the evidence log
App owner Dan The code, its pull requests, dependency fixes, the CI checks
Everyone All staff and contractors Following these policies, reporting anything suspicious at once

When the security owner is away, the platform owner acts for them, and the reverse. A decision taken that way is recorded and shown to the other on return.

3. Code of conduct

  • Act honestly with clients' data and with each other; do not look at a client's records without a work reason.
  • Never share an account, a password or an MFA device. Every action in our systems is one named person's.
  • Report a mistake, a suspected breach, a lost laptop or a policy you cannot follow to the security owner at once, and within 1 hour of noticing. Nobody is blamed for reporting in good faith.
  • Conflicts of interest (a personal stake in a client or vendor decision) are declared to the security owner.

Breaking this policy may lead to access being removed and to disciplinary action or the end of a contract.

4. Acceptable use

Company accounts and SCOPE data are for Lucent Axis work. Client data stays in the client's SCOPE project: it is not copied to a laptop, a personal account, a chat tool, an AI tool outside our contracted ones (Spotter's model under its own terms), or email, except a client's own export handed back to that client.

5. Access control

  • MFA on every company account (ORG-06). No account without it.
  • Least privilege: the lowest role that does the job; owner rights held by at least two people (OW-6).
  • Access is granted with the joining checklist and removed within 24 hours of leaving.
  • Every account is reviewed quarterly (ORG-20); scripts/compliance/access_review.sh produces the member lists for the review.
  • In the app, a user's access follows their role and site through row-level security in the database; the app does not decide on its own what a user may see.
  • Passwords live in the company vault only, never in chat, a document or a repository.

5a. Support access to a client's data

Our staff have no standing access to a client's records. When support needs it:

  1. There is a reason: a request from the client, or an incident. Note it in the support access log below before starting.
  2. Use the narrowest route: the client's own export or a screen share with the client first; an app login at the lowest level that answers the question next; the database password last, and only by the platform owner.
  3. Access ends when the task does. An app login made for it is removed the same day.
  4. The client is told in the contract that this can happen and how it is logged.
Date Who Client Reason Route (export, screen share, app login and level, database) Ended

"View as anyone" signs in as any person. It lives in the demo-only personas add-on (supabase/addons/personas), which is never installed in a client database or switched on in a client build; a client database that has the core migrations has none of its functions.

6. Encryption

  • In transit: TLS everywhere. The app sends HSTS, and the database accepts only TLS (DB-7).
  • At rest: Supabase encrypts the database, backups and storage with AES-256; Vercel encrypts its environment variables. Keys are held by the providers.
  • Laptops: full-disk encryption on (BYOD policy).

7. Secure development and vulnerabilities

  • Every change follows the change management policy.
  • Secrets: gitleaks scans every commit and the whole history in CI (ORG-03).
  • Dependencies: Dependabot alerts are watched. Critical fixes within 7 days, High within 30, counted from the alert. A fix that cannot be made in time is recorded in the risk register with the reason and the date it will be (ORG-26).
  • Code: static analysis in CI (SC-7).
  • An automated scan (OWASP ZAP) at least yearly and before the Type I, alongside the RLS proofs in scripts/db/verify_*.sql; a third-party pen test before the first enterprise client goes live (LM-4). Findings tracked to closure in the evidence log.
  • Anyone who finds a vulnerability reports it to the security owner the same day.

8. Malware

  • Laptops: the operating system's own protection on and current (macOS XProtect and Gatekeeper, Windows Defender), as the BYOD policy requires.
  • Uploads into SCOPE: private buckets, a 25 MB limit and an allowed list of file types per bucket; files are never executed, only stored and served back by signed URL. Location data is stripped from JPEG photos before upload (ST-3).

9. Exceptions

An exception to any of these policies is asked for from the security owner, granted in writing with an end date, and recorded in the risk register.

Back to top