Information Security Policy

Effective Date: 2026-03-02 Last Review: 2026-03-02 Next Review: 2026-09-02 Owner: Greg Felice, Project Lead

1. Purpose

This policy establishes the security framework for the tomo project — its open-source SDK, Docker distribution, hosted service, and supporting infrastructure. It defines the organizational commitment to protecting the confidentiality, integrity, and availability of information assets.

2. Scope

This policy applies to:

• Tomo SDK — the open-source Python package distributed via PyPI
• tomo Docker image — the PostgreSQL + AGE + pgvector container distributed via Docker Hub
• tomo hosted service — the evaluation and production database-as-a-service at tomo.rizlabs.com
• Infrastructure — servers, CI/CD pipelines, monitoring, and backup systems
• Contributors — anyone with commit access or infrastructure credentials
• Users — anyone using the hosted service (data protection obligations)

3. Principles

1. Defense in depth — No single control is sufficient. Layer authentication, encryption, logging, and monitoring.
2. Least privilege — Grant minimum access needed for each role. Review quarterly.
3. Secure by default — Ship secure configurations. Users should have to opt out of security, not opt in.
4. Transparency — Publish our security posture, vulnerability process, and incident history openly.

4. Roles and Responsibilities

Role	Responsibility
Project Lead	Policy ownership, risk acceptance decisions, incident escalation
Contributors	Follow contributor security policy, report vulnerabilities, review code for security
Infrastructure Owner	Server hardening, access management, backup verification, monitoring
Users (hosted service)	Credential management, client-side TLS configuration, data classification

5. Information Classification

Classification	Description	Examples	Handling
Public	Intended for public access	SDK source code, documentation, Docker image	No restrictions
Internal	Not public, low sensitivity	Architecture decisions, backlog, CI configs	Access-controlled repos
Confidential	Sensitive, access-restricted	API keys, credentials, user data, infrastructure configs	Encrypted at rest and in transit
Restricted	Highest sensitivity	TLS private keys, database master passwords, user PII	Hardware-backed encryption, minimal access

See Data Classification Policy for detailed handling requirements.

6. Core Controls

6.1 Access Control

• All infrastructure access requires named accounts (no shared credentials)
• SSH key authentication only (password auth disabled)
• MFA required for Authentik SSO (covers Forgejo, Grafana, admin panels)
• Database roles follow least-privilege model
• API keys scoped to minimum required permissions

See Access Control Policy for details.

6.2 Encryption

• In transit: TLS 1.2+ required for all PostgreSQL connections and HTTP APIs
• At rest: LUKS disk encryption for hosted service data volumes
• Backups: Encrypted before offsite transfer (AES-256)
• Secrets: Stored in environment variables or secrets manager, never in code

6.3 Audit Logging

• PostgreSQL: connections, disconnections, DDL statements logged
• API: all requests logged with timestamp, source IP, user, action
• Auth: all login attempts (success and failure) logged
• Infrastructure: SSH access logged via systemd journal
• Retention: 90 days minimum for all log categories

6.4 Vulnerability Management

• SAST: bandit runs on every push (blocks merge on medium+ findings)
• Dependency audit: pip-audit runs on every push (blocks merge on known CVEs)
• Container scan: trivy scans Docker image on main branch pushes
• Secret scan: trufflehog scans repository on main branch pushes
• CIS benchmark: pgdsat runs nightly against Docker image

See SECURITY.md for vulnerability disclosure and SLA.

6.5 Change Management

• All code changes require pull request review
• CI pipeline gates: lint, typecheck, unit tests, SAST, dependency audit
• Infrastructure changes tracked in version-controlled Ansible/Terraform
• Deploy approvals required for production changes

See Change Management Policy for details.

6.6 Incident Response

• Documented detection, triage, containment, recovery, and post-mortem process
• Severity classification with defined response timelines
• Post-incident review within 5 business days

See Incident Response Plan for the full process.

6.7 Backup and Recovery

• Automated daily backups via pg_basebackup
• WAL archiving for point-in-time recovery
• Encrypted offsite copies to S3-compatible storage
• Weekly automated restore tests
• Recovery time objective (RTO): 4 hours
• Recovery point objective (RPO): 1 hour

See Backup and Recovery Policy for procedures.

6.8 Network Security

• Firewall rules: only required ports open (SSH, PostgreSQL, HTTPS)
• Default deny: inbound traffic blocked unless explicitly allowed
• VLAN segmentation between services where applicable
• No direct internet exposure of PostgreSQL (hosted service uses PgBouncer proxy)

7. Compliance

This policy is designed to align with SOC 2 Type II Trust Service Criteria (Security). The project is building toward formal certification with the goal of entering the audit observation period once all controls have been operational for 3-6 months.

Additional frameworks considered for future alignment:

• ISO 27001 (European enterprise customers)
• HIPAA (healthcare use cases)

8. Policy Review

This policy is reviewed semi-annually or upon:

• A security incident
• A significant change in infrastructure or services
• New compliance requirements
• Addition of new team members or contributors

9. Exceptions

Exceptions to this policy require documented approval from the Project Lead, including:

• Business justification
• Risk assessment
• Compensating controls
• Expiration date

Exceptions are tracked in the risk assessment document and reviewed quarterly.