Information Security Policy

Effective March 5, 2026 · Approved by Sean Appleby, CEO

1. Purpose & Objectives

This Information Security Policy (ISP) establishes seanCo's commitment to protecting the confidentiality, integrity, and availability of all information assets within the attune platform. Attune processes deeply personal data—journal entries, goals, health observations, financial summaries, and location context—and we treat the security of that data as a core product obligation, not an afterthought.

Our objectives are to:

1. Protect user data against unauthorized access, disclosure, alteration, or destruction.
2. Maintain the availability and resilience of attune's services.
3. Comply with applicable privacy and security regulations.
4. Foster a culture of security awareness across the organization.
5. Continuously improve our security posture through regular assessment and iteration.

2. Scope

This policy applies to:

• All information assets owned or managed by seanCo, including production infrastructure, source code, databases, backups, and internal tools.
• All personnel—employees, contractors, and any third party with access to seanCo systems.
• All environments—production, staging, development, and local development machines that connect to seanCo services.
• All data processed by the attune platform, including data at rest, in transit, and in use.

3. Accountability

3.1 Executive Ownership

The CEO is the accountable owner of this policy and is responsible for ensuring adequate resources are allocated to information security. The CEO reviews and approves this policy at least annually.

3.2 Engineering

All engineers are responsible for:

• Writing secure code and following the secure development practices outlined in our codebase standards.
• Reviewing pull requests for security implications.
• Reporting suspected vulnerabilities or incidents immediately.

3.3 Third-Party Providers

Third-party services (Google Cloud Platform, Plaid, Anthropic, PowerSync) are selected based on their security posture and are bound by data processing agreements that meet or exceed the controls in this policy.

4. Information Classification

• Restricted — Authentication credentials, encryption keys, API secrets, Plaid access tokens. Access limited to systems that require them; never stored in source code.
• Confidential — User-generated content (journals, observations, goals, financial data, location). Encrypted at rest and in transit; access limited to the owning user and authorized backend processes.
• Internal — Source code, infrastructure configuration, internal documentation. Access limited to seanCo personnel.
• Public — Marketing site, published policies, app store listings.

5. Key Security Controls

5.1 Encryption

• In transit: All network communication uses TLS 1.2+ (HTTPS enforced for API, PowerSync, and web).
• At rest: PostgreSQL and backup storage use AES-256 encryption via GCP's default encryption. Sensitive fields (tokens, keys) use application-layer encryption.
• Local device: The Flutter app stores data in an encrypted local SQLite database via PowerSync.

5.2 Access Control

Covered in detail in the Access Control Policy. In summary: least privilege by default, role-based access, MFA required for all infrastructure access.

5.3 Secure Development

• Pre-commit hooks enforce code quality and prevent credential leakage.
• CI pipelines run automated tests and security checks on every push.
• Dependencies are monitored for known vulnerabilities.
• Signing keys for app store releases are rotated on a defined schedule and never stored in source control.

5.4 Infrastructure Security

• Production runs on Google Kubernetes Engine (GKE) with network policies restricting pod-to-pod communication.
• Infrastructure is defined as code (Terraform) and changes are reviewed before apply.
• Database access is restricted to application service accounts; no direct human access to production databases under normal operation.
• Read-only database access for debugging uses a dedicated restricted user.

5.5 Logging & Monitoring

• Application and infrastructure logs are collected centrally.
• Health check and sync endpoints are filtered from alert pipelines to reduce noise.
• Anomalous access patterns trigger alerts for investigation.

6. Risk Management

6.1 Risk Assessment

We conduct risk assessments when:

• Introducing new third-party integrations (e.g., Plaid for financial data, calendar providers).
• Making significant architectural changes.
• Annually as part of the policy review cycle.

6.2 Identified Risks & Mitigations

• Sensitive personal data exposure: Mitigated by encryption at rest/transit, row-level access control (users can only access their own data), and PowerSync sync rules that enforce per-user data boundaries.
• Third-party compromise: Mitigated by limiting data shared with third parties, using scoped API tokens, and monitoring for anomalous third-party behavior.
• AI pipeline data leakage: Mitigated by processing user data in isolated per-request contexts; AI providers (Anthropic) do not retain input data for training.
• Supply chain attacks: Mitigated by dependency pinning, lock files, and CI guardrails on signing keys.

7. Incident Response

1. Detection: Incidents may be detected via monitoring alerts, user reports, or third-party notifications.
2. Containment: Immediately isolate affected systems. Revoke compromised credentials. Scale down affected deployments if necessary.
3. Investigation: Determine scope, root cause, and affected data. Preserve logs for analysis.
4. Notification: Affected users are notified within 72 hours of confirmed data breaches, in compliance with applicable regulations.
5. Remediation: Fix root cause, deploy patches, and update controls to prevent recurrence.
6. Post-mortem: Document the incident, response, and lessons learned. Update this policy if needed.

8. Business Continuity

• Automated daily backups of PostgreSQL with 30-day retention.
• Infrastructure defined as code enables rapid environment recreation.
• The offline-first architecture (PowerSync) ensures users retain access to their data even during service outages.

9. Policy Review

This policy is reviewed and approved by the CEO at least annually, or whenever a material change to the security environment occurs (new integrations, infrastructure changes, or incidents). All updates are versioned and communicated to relevant personnel.

10. Contact

Security concerns or questions about this policy can be directed to you@snappleby.xyz.