Information Security Policy

This Information Security Policy describes the certifications Didit holds, the technical and organizational controls Didit operates, and the trust artifacts available to customers, prospective customers, regulators, and auditors. It is reviewed at least every six months.

• Security contact: security@didit.me
• Data Protection Officer: dpo@didit.me
• Status page (real-time): status.didit.me
• Trust pack (under NDA): email security@didit.me

1. Certifications and attestations

To request any of the underlying reports or certificates, email security@didit.me. Reports restricted under their issuer's terms (for example, SOC 2 Type 1) are shared after a signed Non-Disclosure Agreement (NDA), the same business day.

2. Scope

This policy covers all Didit personnel (employees, contractors, and authorized third parties), all Didit production and corporate information systems, and the customer-facing Services described in the Business Terms and Conditions. It is supported by the Statement of Applicability that anchors Didit's ISO/IEC 27001:2022 management system.

3. Governance

• Information Security and Privacy Management System aligned to ISO/IEC 27001:2022 and ISO/IEC 27701 controls, with a documented Statement of Applicability.
• Chief Technology Officer is the named information-security executive sponsor; the Data Protection Officer (dpo@didit.me) owns privacy program governance.
• Annual external security audit by independent auditors (ISO 27001 surveillance and SOC 2 examinations).
• Risk register reviewed and refreshed quarterly. Material risks are escalated to the management committee.
• Continuous improvement — every incident, audit finding, and risk assessment feeds the corrective-action backlog and the next policy refresh.

4. Encryption and key management

• At rest: AES-256 across every production database, object store, and backup volume.
• In transit: TLS 1.3 for every external API call, webhook, and Business Console session. Older TLS versions and weak ciphers are disabled. HTTP Strict Transport Security (HSTS) is enforced site-wide and preloaded.
• Key management: AWS Key Management Service (KMS) holds and rotates the keys. Application code never touches raw key material. Sandbox and production keys are fully separated.
• Hashing: customer credentials are hashed with industry-standard adaptive functions (bcrypt or equivalent). API keys are stored as one-way hashes; the raw value is shown to the operator only at creation time.

5. Identity, access, and zero-trust architecture

• Zero-trust by default — every request to every internal system is authenticated and authorized. There is no implicit trust based on network location.
• Role-based access control (RBAC) with the principle of least privilege. Access reviews are run quarterly.
• Multi-Factor Authentication (MFA) is mandatory for every employee, every production system, every cloud console, and every code-hosting account.
• Single Sign-On (SSO) for internal applications, with hardware-token MFA for privileged roles.
• Just-in-Time access for production: standing privileged access is the exception, not the rule.
• Audit logging — every privileged action is logged to a tamper-evident, write-once audit pipeline retained for at least 12 months.

6. Data residency and segregation

• European Union by default. Production data is processed and stored in the European Union on Amazon Web Services. Specific-region or in-country residency is available on Enterprise contracts, subject to availability, for jurisdictions whose regulators require it.
• Environment separation. Sandbox, staging, and production are isolated at the network, identity, and key-management layers. No human or service in one environment can read data in another without an explicit, audited access path.
• Tenant separation. Multi-tenant data is logically separated with per-tenant encryption keys where applicable. Cross-tenant queries are blocked at the application and database layer.

7. Secure development lifecycle (SDLC)

• Code review is required for every production change. No single engineer can merge unreviewed code to production.
• Static Application Security Testing (SAST), dependency scanning, and Software Composition Analysis (SCA) run automatically on every pull request.
• Container and infrastructure scanning on every build and on a recurring schedule for deployed images.
• Pre-production security testing for high-impact changes (authentication, key management, biometric pipelines, payment flows).
• Internal penetration tests continuously; external penetration tests at least once per year by independent specialists. Material findings are tracked to closure on an SLA-bound schedule.
• Bug-bounty / responsible-disclosure channel — report security issues to security@didit.me.

8. Vulnerability management

• Patching SLA by severity — critical (within 72 hours of vendor disclosure), high (within 7 days), medium (within 30 days), low (within 90 days).
• Continuous vulnerability scanning across production infrastructure, containers, and dependencies.
• Threat modeling for new product surfaces, biometric pipelines, and cross-environment integrations.

9. Monitoring, detection, and incident response

• 24x7 monitoring of every production system with alerting on availability, error, and security signals.
• Security Information and Event Management (SIEM) aggregates and correlates security events; abnormal patterns escalate to on-call security engineers.
• Documented Incident Response Plan with named roles, communication tree, severity matrix, and post-incident review process. The plan is tested at least annually via tabletop exercises.
• Personal data breach notification. Didit notifies affected customers without undue delay and in any case in time to allow customers to meet their own 72-hour notification obligation under General Data Protection Regulation (GDPR) Article 33. Enterprise customers receive a named engineer on call and a dedicated communication channel.
• Public status page at status.didit.me — every production incident, every post-mortem, no login required.

10. Business continuity and disaster recovery

• Multi-AZ active redundancy in every production region; automatic failover for stateless services.
• Backups are encrypted, geographically separated within the chosen residency boundary, and tested on a recurring schedule.
• Recovery Point Objective (RPO) ≤ 1 hour and Recovery Time Objective (RTO) ≤ 4 hours for the core verification API and Business Console.
• Disaster Recovery (DR) tests at least annually.

11. Personnel security

• Background checks on every employee and every contractor with access to production data or personal data, where permitted by applicable law.
• Confidentiality agreements at hire for every employee and contractor.
• Mandatory security and privacy training at onboarding and refreshed at least annually for every employee. Targeted training (secure coding, biometric data handling, anti-fraud, anti-money-laundering) for the roles that need it.
• Phishing simulations on a recurring schedule.
• Joiner / mover / leaver process revokes access within 24 hours of role change or departure.

12. Vendor and sub-processor management

• Every sub-processor is risk-assessed before onboarding and re-reviewed at least annually.
• Every sub-processor signs a Data Processing Agreement (DPA) imposing data-protection obligations substantially similar to those Didit owes its own customers.
• The current sub-processor list is shared with customers and prospective customers via email after a Non-Disclosure Agreement (NDA) is signed. Email security@didit.me to request it. Customers subscribed to sub-processor change notifications are notified by email with sufficient advance notice to object.

13. Data subject rights and deletion

• Right of access and portability — `GET /v3/sessions/:session_id/decision/`.
• Right to erasure — `POST /v3/sessions/:session_id/delete/`. Removes the session and every linked artifact across every replica.
• Per-application retention is configurable in the Business Console between 30 days and 10 years; the default is indefinite unless the customer configures a shorter period. Biometric data retention is in every case subject to, and capped by, applicable biometric-privacy laws and regulations — including the EU General Data Protection Regulation (GDPR) Article 9, the Illinois Biometric Information Privacy Act (BIPA), the Texas Capture or Use of Biometric Identifier Act (CUBI), Washington H.B. 1493, and any other applicable biometric-privacy law; where such law prescribes a shorter retention period or an earlier destruction obligation, that shorter or stricter rule prevails over any default or customer-configured retention period.
• See the Privacy Policy and Verification Privacy Notice for the full data-subject-rights process.

14. Reporting a security issue

If you believe you have found a security vulnerability in any Didit product or service, email security@didit.me with a description, reproduction steps, and the impact you observed. Didit acknowledges security reports within 2 business days and works in good faith with reporters who follow responsible-disclosure practices.

15. Contact

• Security: security@didit.me
• Data Protection Officer: dpo@didit.me
• Privacy: privacy@didit.me
• Legal / contracts: legal@didit.me
• Trust pack request (under NDA): security@didit.me