SOC 2 Aligned
Security Controls
HADESS implements security controls aligned with the AICPA SOC 2 Trust Service Criteria. This page documents our controls, policies, and compliance posture.
Last comprehensive review: March 2026. Controls are continuously monitored and updated.
SOC 2 Alignment Status
HADESS has implemented controls aligned with all five SOC 2 Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Our controls are documented below with supporting evidence.
Trust Service Criteria
Security
Availability
Processing Integrity
Confidentiality
Privacy
Security Policies
Access Control Policy
Last updated: March 2026
Principle of Least Privilege
All system access is granted based on the principle of least privilege. Users receive only the minimum permissions necessary to perform their role. Access is reviewed quarterly and revoked promptly upon role change or termination.
Authentication Requirements
All user authentication is handled through OAuth 2.0 providers (Google, Microsoft Azure AD, GitHub, Apple) with verified email addresses. Multi-factor authentication is enforced through the OAuth providers. No password-based authentication is offered to end users, eliminating password-related attack vectors.
Role-Based Access Control (RBAC)
The platform implements four user roles: ADMIN (platform administrators), ENTERPRISE (enterprise account managers), PROFESSIONAL (standard users), and COACH (career coaches). Each role has clearly defined permissions enforced at the API level. Enterprise SSO provisions users automatically with the MEMBER role — admin must explicitly assign elevated roles.
Administrative Access
Administrative access to production infrastructure is restricted to authorized personnel via SSH key authentication. All administrative actions are logged. The admin password is a cryptographically random 32-character string rotated regularly.
Third-Party Access
Third-party integrations (Stripe, OAuth providers) access only the data necessary for their function. API keys are stored as environment variables and never committed to source control. Access is reviewed when vendor relationships change.
Incident Response Plan
Last updated: March 2026
Incident Classification
Security incidents are classified into four severity levels: Critical (active data breach, RCE, authentication bypass — response within 1 hour), High (privilege escalation, data exposure — response within 4 hours), Medium (XSS, CSRF, information disclosure — response within 24 hours), and Low (missing headers, configuration issues — response within 72 hours).
Detection & Reporting
Incidents are detected through: UptimeRobot monitoring (availability), server logs (security events), user reports, and our Vulnerability Disclosure Program (security@hadess.io). All team members are trained to recognize and report potential security incidents immediately.
Response Procedure
Upon detection: (1) Immediately contain the incident by isolating affected systems. (2) Assess scope and impact — identify affected users and data. (3) Eradicate the root cause through patching or configuration changes. (4) Recover services with verification that the fix is effective. (5) Conduct post-incident review within 48 hours.
Communication
Affected users are notified within 72 hours of a confirmed data breach, as required by GDPR. Notification includes: nature of the breach, data affected, actions taken, and recommended user actions. The public status page (UptimeRobot) is updated for availability incidents.
Post-Incident Review
Every Critical and High severity incident triggers a blameless post-mortem within 48 hours. The review documents: timeline of events, root cause analysis, impact assessment, remediation actions taken, and preventive measures to avoid recurrence. Findings are incorporated into security training and process improvements.
Vendor Risk Management
Last updated: March 2026
Vendor Assessment Criteria
All third-party vendors processing user data are evaluated against: SOC 2 compliance status, data encryption practices, incident response capabilities, data processing agreements, and GDPR compliance. Only vendors meeting our security baseline are approved.
Approved Vendors & Compliance Status
Stripe (payment processing) — SOC 2 Type II, PCI DSS Level 1 certified. Google OAuth — SOC 2 Type II, ISO 27001 certified. Microsoft Azure AD — SOC 2 Type II, ISO 27001, FedRAMP certified. GitHub OAuth — SOC 2 Type II certified. Apple Sign-In — ISO 27001, SOC 2 Type II certified. Vercel/Infrastructure — SOC 2 Type II certified. UptimeRobot (monitoring) — GDPR compliant.
Data Processing Agreements
Data Processing Agreements (DPAs) are in place with all vendors who process personal data. DPAs specify: data handling obligations, sub-processor requirements, breach notification timelines, data deletion procedures, and audit rights.
Ongoing Monitoring
Vendor compliance is reviewed annually or upon notification of a vendor security incident. Vendors are required to notify us of material changes to their security posture. Non-compliant vendors are given 30 days to remediate or are replaced.
Data Residency
Primary data processing occurs in EU-based infrastructure in compliance with GDPR. Stripe payment data is processed in Stripe's PCI-certified environment. OAuth tokens are processed by respective providers in their certified environments. No user data is transferred to jurisdictions without adequate data protection laws without explicit user consent.
Certifications & Standards
Stripe PCI DSS Level 1
Payment processing handled by Stripe, a PCI DSS Level 1 certified service provider
GDPR Compliant
Full compliance with EU General Data Protection Regulation including DPA with all processors
OAuth 2.0 + PKCE
Industry-standard authentication with Proof Key for Code Exchange across all providers
TLS 1.2/1.3
All data encrypted in transit using modern TLS with strong cipher suites
Questions About Our Security?
For security inquiries, compliance documentation requests, or to report a vulnerability, contact our security team.