Information Security Policy

Organization: Strategic Habits Consulting, LLC, doing business as Gevell and TheAccessible.Org (“the Company”) Owner: Larry Anglin, CTO Effective date: 2026-09-23 Review cadence: Annually, and after any security incident or significant change to the platform

1. Purpose and scope

This policy sets out how the Company protects the confidentiality, integrity and availability of customer data and of the systems that deliver Gevell PDF (pdf.gevell.com) and the related Gevell apps.

It covers:

• all Company members, and any future employees or contractors;
• all production systems: AWS (Lambda, API Gateway, SQS, S3 and Bedrock in us-east-1 and us-east-2), Cloudflare (Pages, CDN, R2, Tunnels and Access), Supabase (PostgreSQL and Auth, hosted on AWS us-east-2), and the document processing host on AWS EC2 (us-east-1);
• the laptops, accounts and source code repositories used to build and run those systems.

The Company has two members and no other employees or contractors. This policy is written for that size. Where a control depends on having a second person, the policy says so.

2. Roles and responsibilities

Role	Person	Responsibilities
CTO / security owner	Larry Anglin	Owns this policy and the security program. Runs development and operations. He is the only person with production infrastructure access (AWS, Cloudflare, Supabase). Approves access, exceptions and subprocessors. Leads incident response.
Chief Accessibility Officer	Laura Hopkins	Owns product accessibility, customer implementation and support. Has no production infrastructure access. Reports suspected security issues to the CTO right away.

Security contact for customers and researchers: [email protected].

3. Data classification

Class	Examples	Handling
Restricted	Credentials, API keys, signing secrets, encryption keys	Kept only in managed secret stores (Cloudflare Worker secrets, AWS SSM Parameter Store SecureString, GitHub Actions secrets, Supabase Vault) or in the host environment file on the processing server. Never kept in source control, email, chat or tickets.
Confidential (Customer)	Uploaded documents and their converted outputs, account data, and job metadata. Documents may contain PII and FERPA-covered student records.	Encrypted in transit and at rest. Access limited to the production operator. Used only to provide the service, never for development or testing. Staff do not view document content in normal operation.
Internal	Source code, operational logs, cost records, internal documentation	Kept in private GitHub repositories and Company systems. Logs carry metadata only, never document content.
Public test corpus	Documents downloaded from publicly accessible websites (no login, paywall or access control) to develop and test the service and to research document accessibility, for example accessibility surveys of institutions’ public documents. Some were published by organizations that are, or later become, customers.	Not customer data. It is collected independently of the service and never taken from a customer’s account, uploads or outputs, so a document stays in this class even if its publisher becomes a customer. Kept in the Company’s development asset store, never in production customer storage or mixed into a customer’s account. Used only for development, testing and accessibility research, never to train AI models. Personal information that appears in public documents is not extracted or compiled. Removed on request from the publisher.
Public	Marketing site, help documentation, published policies	No restrictions.

Protected Health Information (PHI). The Company does not process, store, or transmit Protected Health Information (PHI) as part of standard service offerings, and does not execute Business Associate Agreements (BAAs) or equivalent data-handling agreements under its standard terms. Engagements requiring PHI handling or a signed BAA fall outside the standard scope and are evaluated on a case-by-case basis, with pricing and terms determined according to the specific compliance, security, and infrastructure requirements involved. Organizations with these needs should contact the Company directly to discuss requirements before initiating a project. No PHI is accepted until such an engagement is agreed in writing.

4. Access control

• Least privilege. Each person gets only the access their role needs. Production infrastructure access is limited to the CTO.
• MFA. Multi-factor authentication is required on every provider account that can reach customer data or production: AWS, Cloudflare, Supabase, GitHub, Google Workspace and Stripe.
• AWS. Day-to-day access goes through AWS IAM Identity Center (SSO). It issues short-lived, MFA-gated credentials. The AWS root user has no access keys and is used only for tasks that AWS reserves to root. One long-lived IAM access key (cdk-deployer) is kept for break-glass use only. CI/CD reaches AWS through GitHub OIDC and holds no static AWS keys.
• Internal tools. Internal admin sites and internal resources are reached only through Cloudflare Access and Cloudflare Tunnels. They are not exposed directly to the internet.
• Customer-facing authorization. Customer tables in PostgreSQL use row-level security. Admin screens are role-gated. API routes limit each request to the calling user’s or tenant’s data.
• Joiners and leavers. Accounts are granted and removed under the Personnel Onboarding and Offboarding Policy. That policy also sets the quarterly access review.

5. Acceptable use

Anyone working for the Company must:

• use Company systems only for Company business;
• keep customer data inside the production systems named in §1. Customer documents must not be copied to personal accounts, removable media or unapproved services (see Media Handling and Data Disposal Policy);
• never share accounts or credentials, and never put secrets in code, tickets, email or chat;
• keep laptops encrypted, screen-locked and up to date (see §7);
• report a suspected incident, lost device or exposed credential to the CTO right away;
• not send customer data to AI tools or services other than the approved, zero-data-retention inference path (§8).

6. Encryption

• In transit. TLS 1.2 or higher on every hop: browser to Cloudflare, Cloudflare to AWS, services to Supabase, and services to Bedrock. The EC2 processing servers connect only through an outbound, encrypted Cloudflare Tunnel.
• At rest. Cloudflare R2, AWS S3 and Supabase encrypt stored data with AES-256 using provider-managed keys. EC2 processing servers use encrypted EBS volumes, and staff laptops use full-disk encryption.

7. Endpoint and server security

• Staff laptops are personally owned (bring your own device). Remote and on-site work are treated the same: internal resources are reached only through Cloudflare Access and Tunnels, always over encrypted connections.

• Personally owned devices used for Company work must:

  • run a currently supported operating system, with automatic OS and browser updates on;
  • have full-disk encryption on (FileVault), a strong login password, Touch ID or an equivalent, and automatic screen lock within 5 minutes;
  • have the built-in firewall on, and device location / remote erase (Find My) enabled;
  • use the Company’s MFA (passkeys) for every Company account, and keep Company credentials only in the operating system’s keychain or a password manager;
  • not store customer data, except as allowed in the Media Handling Policy §2 for a specific support request.

  Each person confirms these settings when they join and at every quarterly access review. A device that doesn’t meet them may not be used for Company work.

• Lost or stolen device: report it immediately. The CTO revokes that device’s sessions and passkeys and rotates any credentials that were on it.

• Leaving the Company, or selling, giving away or recycling the device: first remove all Company accounts, sessions, passkeys, SSH keys and Company files (including source checkouts and .env files). Before a device leaves the person’s possession, erase it (Erase All Content and Settings). The person confirms this in writing. The Company does not wipe or take possession of personal devices.

• Processing servers run on AWS EC2 in a VPC with no inbound security-group rules; their only inbound path is an outbound Cloudflare Tunnel, and administration is through AWS Systems Manager rather than SSH. Their volumes are encrypted, and they hold customer documents only while they are being processed.

8. Vendor and subprocessor management

• The current subprocessor list, and what customer data each one receives, is kept in our subprocessor register.
• Before a new subprocessor receives customer data, the CTO reviews:
  • its security attestations (SOC 2 or ISO 27001 where available);
  • its data retention and model-training terms;
  • where it stores and processes data. Customer data stays in the United States.
• AI inference on customer documents runs on AWS Bedrock under zero data retention. Customer data is not used to train models. Any path that sends customer content to a non-zero-retention AI provider must be recorded as an exception (§12).
• The subprocessor list is reviewed each year, when this policy is reviewed.

9. Secure development and change management

• Code lives in private GitHub repositories.
• Changes reach main through GitHub pull requests. The main branch has protection turned on, and a required CI status check (gate) must pass before merge. That check covers lint, typecheck and automated tests. An accessibility audit also runs on pull requests.
• Production deploys run only from main.
• Database schema changes use versioned migration files.
• Rollback means redeploying a previous commit.
• Every pull request is reviewed by the CTO with AI-assisted code review and must pass the automated gates before merge.

10. Logging and monitoring

• Application logs are structured JSON with request IDs, user IDs and timings. They never contain document content. Logs from the AWS-hosted API and processing host are kept in Amazon CloudWatch Logs.
• Application alerting covers error rate, fatal errors and missing heartbeats, and Amazon CloudWatch alarms cover queue and API health. AWS GuardDuty threat detection and AWS CloudTrail are enabled on the AWS account, with alerts to the CTO. status.gevell.com checks every production endpoint each minute. Spend-anomaly alerts are in place. Alerts go to the CTO by email and Telegram.
• Admin actions, such as the AI kill switch, are written to an admin audit log. Account deletions are written to an append-only deletion audit table.

11. Incident response, continuity and recovery

• Security incidents are handled under the Incident Response Plan. The Company aims to notify affected customers of a confirmed breach of their data within 72 hours.
• Continuity and recovery are covered by the Business Continuity Plan and the Disaster Recovery Plan.
• Backups:
  • Supabase takes daily encrypted database backups, retained for 7 days.
  • Cloudflare R2 provides durable object storage.
  • Operational data (not customer documents) is backed up each night, encrypted, to Backblaze B2 and kept for 30 days.

12. Exceptions

Any deviation from this policy must be recorded before it takes effect. If that is not possible during an incident, it must be recorded within 2 business days. Each record states:

• what the deviation is and why it is needed;
• the risk it creates;
• the controls that offset that risk;
• who approved it (the CTO);
• when it expires or will next be reviewed. No exception lasts longer than 12 months without renewal.

Exceptions are recorded as GitHub issues labeled security-exception. They are reviewed at each annual policy review.

13. Policy review

The CTO reviews this policy and its companion policies:

• once a year;
• after any security incident;
• when the platform, hosting or staffing changes in a significant way.

Each review is recorded by updating the updated date and adding a line to the change log below.

Date	Change	By
[on adoption]	Initial version	Larry Anglin

Actions required to make this policy true

1. Confirm MFA on every provider account listed in §4 (AWS, Cloudflare, Supabase, GitHub, Google Workspace, Stripe), for both members. Record the result. The HECVAT draft lists this as not yet verified.
2. Create the companion documents this policy relies on: incident-response-plan.md, business-continuity-plan.md and disaster-recovery-plan.md. There is no docs/admin/disaster-recovery.md today, even though the HECVAT draft cites one.
3. Create the security-exception GitHub label. Record the known current exceptions under it:
   • #3052: opus-page-converter uses the Files API outside zero data retention (admin-only);
   • #3090: tools/segment-cli sends content directly to Anthropic without zero data retention;
   • #2243: some runtime secrets still sit in host environment files rather than a managed secret store;
   • the single-engineer pull-request review (§9).
4. Decide whether to turn on “enforce admins” for main branch protection. It is currently off, so an admin can push directly to main and skip the gate check. Either turn it on, or record it as an exception.
5. Check the deploy-from-main rule against manual deploys. Several surfaces are deployed by hand from a workstation:
   • the Node API / processing server deploy;
   • apps/pro;
   • apps/admin;
   • the help site. Either require these to run from a clean main checkout, or change the wording in §9.
6. Fix the company description in the other security documents. hecvat-draft.md describes the Company as “AnglinAI (sole proprietorship of Larry Anglin)”. Update it to Strategic Habits Consulting, LLC (DBA Gevell and TheAccessible.Org), with two members.
7. Bring data-flow-subprocessors.md up to date. It is dated 2026-08-23 and still lists Google Gemini as “being retired”. Also decide whether Twilio and Mathpix need a documented retention review.