Information Security Policy
Information Security Policy
Organisation: Heuristicworks LLC
Product: Spexsure (spexsure.com)
Owner: Parimal Mohile, Founder
Version: 1.1
Effective Date: 2026-07-01
Review Cycle: Annual
1. Purpose
This policy defines the information security principles, responsibilities, and controls that govern how Spexsure collects, stores, processes, and protects customer data and internal systems.
2. Scope
This policy applies to:
- All Spexsure production systems (Vercel, Supabase, Upstash Redis, Cloudflare)
- All third-party integrations (Anthropic, Stripe, Jira, Resend)
- All workstations and accounts used for development and operations
- All personnel with access to customer data or production systems
3. Data Classification, Inventory, and Flow
3.1 Classification
| Class | Examples | Controls |
|---|---|---|
| Confidential | OAuth tokens, API keys, encryption keys, BYOK API keys, MFA secrets | AES-256-GCM at rest; TLS 1.3 in transit; access limited to authorised services |
| Restricted | PRD content (may contain third-party PII), billing records, journey events | Stored in Supabase; access via authenticated tRPC only; PII scanned before AI processing |
| Internal | Error logs, COGS analytics, admin audit logs | Stored in Supabase; ADMIN_USER_ID-gated dashboard; 90-day hot retention |
| Public | Marketing content, legal pages, health endpoint, CAIQ | No restrictions |
3.2 Data Inventory
| Data Type | Storage Location | Retention | Encrypted at Rest |
|---|---|---|---|
| User account (email, name) | Supabase — User table |
Until deletion | Supabase AES-256 |
| OAuth session tokens | Supabase — Session table |
Until expiry | Supabase AES-256 |
| PRD content | Supabase — Project.rawPrd |
30 days post-closure | Supabase AES-256 |
| Jira OAuth tokens | Supabase — Integration table |
Until revoked | AES-256-GCM (app-layer) |
| BYOK API keys | Supabase — Subscription table |
Until deleted | AES-256-GCM (app-layer) |
| MFA TOTP secrets | Supabase — User.mfaSecret |
Until MFA disabled | AES-256-GCM (app-layer) |
| Billing records | Stripe + Supabase — Subscription table |
7 years | Stripe + Supabase AES-256 |
| AI processing records | Supabase — Analysis table |
12 months | Supabase AES-256 |
| Journey/audit events | Supabase — JourneyEvent, AuditLog |
90 days hot, 12 months archive | Supabase AES-256 |
3.3 Data Flow
Customer data traverses the following trust boundaries:
- Browser → Cloudflare → Vercel (Next.js): TLS 1.3; Cloudflare WAF + DDoS protection; rate limiting via Upstash Redis
- Next.js → Supabase: TLS; Prisma parameterised queries; user-scoped access enforced in all mutations
- Next.js / Workers → Anthropic API: TLS; PII scan before transmission; zero data retention per DPA; PRD content not logged
- Next.js → Stripe: TLS; HMAC-SHA256 webhook signature verified; no card data touches Spexsure systems
- Next.js → Jira: TLS; OAuth 2.0 with CSRF protection; tokens AES-256-GCM encrypted at rest
- Next.js → Resend: TLS; transactional only; no bulk marketing without explicit consent
Full data flow is documented in the DPIA (legal/DPIA/spexsure-dpia-2026-07.md).
4. Encryption Standards
- Data at rest: AES-256-GCM for OAuth tokens, BYOK API keys, and MFA secrets stored in the database. Supabase encrypts all data at rest with AES-256.
- Data in transit: TLS 1.3 enforced via Cloudflare. All third-party API calls use TLS 1.2 minimum.
- Backups: Supabase automated backups encrypted at rest using AES-256.
- Secrets: All environment secrets stored in Vercel's encrypted environment variable store. No secrets committed to source control.
- Key rotation: Annual rotation for
ENCRYPTION_KEY,AUTH_SECRET, and all HMAC keys. Rotation procedure atlegal/security/spexsure-encryption-key-rotation.md.
5. Identity and Access Management
5.1 Policy
All access to Spexsure systems and data must be authorised, authenticated, and logged. Access is granted on a least-privilege basis and reviewed quarterly.
5.2 Authentication
- Customer authentication: Google OAuth 2.0 and Microsoft Entra ID OAuth 2.0 via NextAuth v5. No username/password authentication.
- MFA: TOTP-based MFA is enforced for all Spexsure users after a 15-day grace period. Backup codes (bcrypt-hashed) provided at enrolment. Production system accounts (Vercel, Supabase, Stripe, GitHub, Cloudflare) require MFA.
- Session management: Sessions stored in PostgreSQL via PrismaAdapter.
__Host-prefixed HttpOnly cookies. Session lifetime enforced server-side.
5.3 Provisioning and Deprovisioning
- New user: Provisioned automatically via NextAuth
createUserevent — free subscription created, welcome email sent, MFA grace period started. - New team member (operations): Access granted per-system by the Security Owner (Parimal Mohile). Added to access register (
legal/GRC/spexsure-access-review.md). MFA required before any access to production systems. - Departing team member: Access revoked immediately across all in-scope systems. Credentials rotated. Emergency revocation procedure:
legal/GRC/spexsure-access-review.md §5. - User deletion: Self-service via signed unsubscribe link. Cascade deletes all project data, integration tokens, and session records. Logs anonymised per GDPR Art.17. Confirmed by email.
5.4 Privileged Access
- Admin access: Gated by
ADMIN_USER_IDenvironment variable (DB user ID, not email — not guessable from sign-in). Admin dashboard at/admin/*restricted to a single designated account. - Database access: Only the application service account (via
DATABASE_URL) and the owner account (Supabase dashboard, MFA-protected) have production DB access. - No shared accounts: Every person must have their own login. Shared credentials are prohibited.
- Quarterly review: Access register reviewed quarterly —
legal/GRC/spexsure-access-review.md.
5.5 Identity Inventory
Current identity and access inventory is maintained in the access register (legal/GRC/spexsure-access-review.md §3), updated after every access change and reviewed quarterly.
6. Secure SDLC and Application Security
6.1 Development Standards
- All code changes are made via Git commits on a feature branch and merged to
masterafter passing CI checks. - No direct push to
master. All production changes go through the CI pipeline. - Secrets are never hardcoded. Environment variables are used exclusively.
- TypeScript strict mode enforced. No
anytypes in security-critical paths.
6.2 Security Testing
| Stage | Method | Frequency |
|---|---|---|
| Dependency scanning (SCA) | GitHub Dependabot (automated PRs) | Weekly |
| Dependency audit | npm audit --audit-level=critical in CI |
Every push |
| End-to-end testing | Playwright suite (~61 tests) | Every push |
| Dynamic analysis (DAST) | OWASP ZAP against staging environment | Quarterly |
| Threat modelling | STRIDE per trust boundary | Annual |
6.3 Vulnerability Remediation
| Severity | Target Remediation |
|---|---|
| Critical | Within 24 hours |
| High | Within 7 days |
| Medium | Within 30 days |
| Low | Next sprint |
Vulnerabilities are tracked via GitHub Dependabot alerts. Deferred vulnerabilities (e.g. transitive dependency CVEs with no exploit path) are documented with justification in SECURITY.md.
6.4 AI Security
All PRD content submitted to the Anthropic API is scanned by lib/guardrails.ts before the API call:
- 14 prompt injection patterns — blocked requests roll back project status
- PII detection (SSN, credit card Luhn, phone, UK NI) — flagged and logged; does not block
- Output scanned for model refusal patterns
PRD content is not retained by Anthropic beyond the API call per executed DPA.
7. Change Management
7.1 Standard Changes
All code changes follow this workflow:
- Develop on a feature branch; commit to GitHub
- CI —
npm audit --audit-level=critical+ Playwright suite must pass - Deploy to staging — push to
stagingbranch → auto-deploys tostaging.spexsure.comvia Vercel Branch Tracking - Test on staging — verify the change in staging environment before production promotion
- Merge to
master→ auto-deploys tospexsure.com
7.2 Rollback
Every Vercel deployment is preserved. Rollback to any prior deployment is instant via Vercel dashboard → Deployments → Promote to Production. No rebuild required.
7.3 Configuration Baselines
| Component | Baseline | Source of truth |
|---|---|---|
| Security headers | HSTS, X-Frame-Options, CSP, Referrer-Policy, Permissions-Policy | apps/web/next.config.js |
| Environment variables | All required vars documented in .env.example |
apps/web/.env.example |
| Database schema | Prisma schema with approved models | apps/web/prisma/schema.prisma |
| Dependencies | Locked versions in package-lock.json |
apps/web/package-lock.json |
| CI pipeline | Lint, audit, test gates | .github/workflows/ci.yml |
7.4 Emergency Changes
Changes required outside the standard workflow (e.g. security hotfix) must still pass CI and be deployed to staging for a smoke test before production, unless the risk of delay exceeds the risk of skipping staging (P0 incident in progress). Post-emergency: create a review task and update the incident log.
8. Vulnerability and Malware Management
8.1 Vulnerability Detection
- GitHub Dependabot scans all npm dependencies weekly and opens PRs for vulnerable versions.
npm audit --audit-level=criticalruns on every push to main and blocks the build on critical findings.- OWASP ZAP DAST scan run quarterly against
staging.spexsure.com. Report stored atlegal/Pen-test/. - STRIDE threat model reviewed annually (
legal/GRC/spexsure-stride-threat-model.md).
8.2 Malware and Malicious Code Protection
- Supply chain: All dependencies pinned in
package-lock.json. GitHub Dependabot monitors for compromised packages. GitHub Actions workflows pinned to commit SHAs (not tag aliases). - Runtime: Cloudflare Bot Fight Mode and WAF rules block known malicious request patterns before they reach the application.
- AI input scanning:
lib/guardrails.tsdetects and blocks prompt injection and code injection attempts in user-submitted content before reaching the Anthropic API. - No server-side code execution from user input: PRD content is processed as text strings only; never evaluated as code.
9. Logging and Monitoring
- Application errors are captured in real-time via Sentry with full stack traces.
- Journey events (user actions) are logged to the database with timestamps, IP address, and user agent.
- Automated breakpoint monitoring runs every 15 minutes; alerts sent to
support@heuristicworks.comon threshold breach. - Logs do not contain plaintext credentials, OAuth tokens, API keys, or unnecessary PII.
- Full log retention schedule:
legal/GRC/spexsure-audit-log-retention.md.
10. Incident Response
Spexsure maintains a documented Incident Response Plan at /security/incident-response.md. The plan defines P0–P3 severity levels, detection, triage, containment, eradication, recovery, and post-mortem procedures, including 72-hour GDPR Art.33 breach notification to ICO. The plan is reviewed and tested annually.
11. Third-Party Risk
All sub-processors are listed at https://spexsure.com/legal/subprocessors. Data Processing Agreements are executed with all 9 sub-processors. Sub-processor security posture:
| Sub-processor | Role | Certifications |
|---|---|---|
| Vercel | Hosting | SOC 2 Type II |
| Supabase | Database | SOC 2 Type II |
| Cloudflare | WAF / CDN / DDoS | SOC 2 Type II, ISO 27001 |
| Anthropic | AI API | SOC 2 Type II |
| Stripe | Payments | PCI DSS Level 1 |
| Resend | SOC 2 Type II | |
| PostHog | Analytics | SOC 2 Type II |
| Upstash | Redis / Rate limiting | SOC 2 Type II |
| Atlassian | Jira integration | SOC 2 Type II, ISO 27001 |
12. Human Resources Security
Spexsure is currently operated by a sole founder. The following controls will be implemented upon first hire.
- Background verification: Reference and identity checks conducted prior to granting access.
- Employment agreements: All employees and contractors will sign agreements including confidentiality obligations, acceptable use, and security responsibilities.
- Security training: Security awareness training provided within 30 days of hire and annually thereafter.
- Access on departure: All system access revoked and credentials rotated on the effective date of departure.
- Disciplinary process: Policy violations reported to
security@spexsure.com. Confirmed violations may result in access revocation and disciplinary action per applicable employment law.
13. Physical Security
Spexsure is a cloud-native SaaS product with no physical data centre infrastructure. Physical security controls are delegated to sub-processors (Vercel/AWS for hosting, Supabase/AWS for database), all of which maintain SOC 2 Type II certification covering physical security.
Development is conducted on password-protected, full-disk-encrypted workstations with automatic screen lock after 5 minutes of inactivity.
14. Policy Exceptions
Exceptions to this policy must be documented with a risk justification and approved by the Security Owner (Parimal Mohile). Known exceptions are tracked in SECURITY.md under "Known Accepted Risks". Exceptions are reviewed at the next annual policy review.
15. Review
This policy is reviewed annually or following any significant security incident or architecture change. The next scheduled review is 2027-07-01.
Approved by: Parimal Mohile, Founder, Heuristicworks LLC
Date: 2026-07-01