1. Hosting and data residency
- All customer data lives in a single AWS region:
eu-central-1(Frankfurt, Germany). No cross-region replication of customer data. - Every AWS service we use — DynamoDB, S3, Lambda, SQS, EventBridge, Secrets Manager, Cognito, Bedrock, Transcribe, Polly, SES — runs in
eu-central-1. - The marketing site (
smarthire.chat) and the dashboard (app.smarthire.chat) are served via CloudFront, an edge network. Only static assets are cached at the edge; all API calls terminate ineu-central-1.
2. Encryption
At rest
- DynamoDB (main table + messages table): AWS-managed KMS keys, per-table encryption always on.
- S3 buckets (CV uploads, voice-note audio, deployment artifacts): server-side encryption (SSE-S3) enabled on every bucket.
- Secrets Manager (Meta app secret, third-party API keys, etc.): KMS-encrypted with automatic key rotation available.
- CloudWatch Logs: encryption at rest via AWS-managed KMS.
In transit
- Every public endpoint (marketing site, dashboard, API gateway, webhook) requires TLS 1.2 or higher. TLS 1.0/1.1 are rejected at the edge.
- Inbound webhooks from Meta / WhatsApp are verified against Meta's HMAC signature on every request. Unsigned or invalid-signature payloads are rejected with 401.
- Internal AWS-to-AWS traffic (Lambda → DynamoDB, Lambda → Bedrock, etc.) travels over the AWS backbone and terminates at TLS endpoints; nothing rides plaintext.
3. Access controls
- Customer dashboard users sign in via Amazon Cognito with email/password or Google. MFA is available and can be required per organization.
- Session tokens are short-lived JWTs, validated on every API request against the Cognito pool.
- Role-based access control: four roles are supported —
org_admin,recruiter,hiring_manager,interviewer. Every backend endpoint declares the minimum role required. Hiring managers see only jobs they are explicitly assigned to. - Tenant isolation is enforced at the data-access layer: every database read and write includes the caller's
tenant_idas part of the DynamoDB partition key. Cross-tenant access is not physically possible through the API. - SmartHire employee access to production data is limited to a small number of engineers, gated by named IAM roles, MFA, and short-lived credentials. Access to production is logged.
4. Audit logging
- Application-level audit log: append-only DynamoDB rows record admin actions (invites, role changes, tenant setting changes), GDPR erasure executions, hiring-manager decisions, and other high-value events. Audit rows can be viewed by tenant admins.
- Infrastructure-level logs: every Lambda invocation and API Gateway request emits a structured CloudWatch log line. Log retention is 30 days; longer retention for security-relevant subsets can be configured on request.
- AWS CloudTrail: all AWS control-plane actions in the SmartHire account are logged and retained.
5. AI and machine learning policy
- SmartHire runs LLM inference on Amazon Bedrock, using Anthropic Claude models. Bedrock is stateless per call — each request is independent and prompts are not retained by the model provider.
- Per AWS Bedrock policy, customer prompts and completions are not used to train the underlying foundation models. AWS documents this at
docs.aws.amazon.com/bedrock. - SmartHire does not fine-tune models on candidate data. We do not share candidate content with any third-party AI vendor outside the Bedrock service.
- The screening bot is instructed via a system prompt that changes rarely and is version-controlled. Prompt behavior is tested against a benchmark suite before rollout.
6. Certifications and compliance
Honest status: SmartHire itself is not yet SOC 2 or ISO 27001 certified. We plan to pursue SOC 2 Type II as the company matures. Ask us for the current roadmap.
The underlying AWS infrastructure we build on is independently certified to a wide range of standards, including SOC 1 / SOC 2 / SOC 3, ISO 27001, ISO 27017, ISO 27018, HIPAA, PCI-DSS, and GDPR. AWS publishes its full attestation catalog at aws.amazon.com/compliance/programs.
What that means in practice: the underlying hosting, encryption, physical security, and access-control primitives are already independently audited. SmartHire builds its application-level controls on top of that foundation. Our own SmartHire-level certification will attest to the way we use those primitives.
7. Vulnerability disclosure
If you believe you've found a security issue, please report it to security@smarthire.chat. Include enough detail to reproduce it. We will:
- Acknowledge receipt within 2 business days.
- Give you a status update within 10 business days.
- Coordinate a disclosure timeline with you before publishing details of the fix.
- Publicly credit reporters who wish to be credited.
Please do not run automated scanners against the production environment. Test against your own tenant, and do not access data belonging to other customers.
8. Incident response
- We have an on-call rotation and a documented incident-response playbook covering triage, containment, forensics, customer notification, and post-mortem.
- In the event of a personal-data breach, we notify affected customer controllers without undue delay and no later than 72 hours after we become aware of it, in line with GDPR Article 33.
- Notifications include: the nature of the incident, categories and approximate number of individuals affected, likely consequences, and the measures we've taken or propose to mitigate the impact.
9. Business continuity
- DynamoDB tables run in multi-AZ mode within
eu-central-1— data is synchronously replicated across three Availability Zones inside the region. - S3 storage is durable across multiple AZs (11 nines of durability per AWS SLA).
- Lambda functions and API Gateway are inherently multi-AZ.
- Recovery Point Objective (RPO): seconds — DynamoDB point-in-time-recovery is enabled, so we can restore to any second in the last 35 days.
- Recovery Time Objective (RTO): minutes to hours for a full-region incident, depending on scope. Recovery playbook is tested periodically.
10. Vendor management
Every sub-processor is listed at /subprocessors/ with its purpose, region, and transfer mechanism. Changes trigger a 30-day notice to customers.
11. Where to go next
- Privacy policy — what data we handle, why, and your rights.
- Data processing agreement — the contractual terms governing our processor role.
- Subprocessors — the vendors we rely on.
- Terms of service — the commercial terms.
- 2026-07-20 Initial published version.