Vendor Security Questionnaire — Quick Answers

For security & vendor-risk teams — the standard questionnaire categories, answered up front. Every answer matches a published document (linked) and the production controls. For a full CAIQ or SIG response, email security@adtosign.com.

Company & service overview

• Product: Enterprise email-signature management (design, deploy, enforce), banners, and a review/reputation engine.
• Registered office: 1st Floor, Oxford Towers, Kodihalli, Bangalore, Karnataka 560008, India.
• Security contact: security@adtosign.com (48-hour response, good-faith disclosure) · security.txt at /.well-known/security.txt
• Details: Security Policy §0

Data handling & retention

• Signature configuration and directory data live in your organization's regional database (US, India, EU, APAC, or GDPR-isolated LTD).
• Email routed through the signature gateway is never stored on successful delivery. Failed-delivery buffers: ≤72h (encrypted, region-locked); undeliverable messages ≤30 days, then automatically and permanently deleted; delivery metadata ≤30 days. The add-in and native signature paths route no mail through AdtoSign at all.
• Details: Email Data Handling · Privacy Policy §1.6

Email routing & authentication custody

• Routing is opt-in per organization; the add-in and native-mailbox paths route zero mail through us.
• The gateway's signature insertion is content-blind: it parses the MIME envelope only (structure, never content analysis) and swaps a signed wrapper token for the signature HTML — no indexing, no human reading, no model training on message content.
• SPF include authorizes gateway egress IPs only. DKIM: one selector-scoped key per organization, private keys in Azure Key Vault (never in our database), delegated by a single CNAME you control — revocation is one DNS change. Your provider's own DKIM keys never enter AdtoSign custody.
• Details: Email Data Handling — authentication

Infrastructure & hosting

• Linode (Akamai): per-region managed PostgreSQL 18, application hosting, signature gateway VMs, region-local Redis. Microsoft Azure: Key Vault, Functions, blob storage. Cloudflare: edge/WAF/DDoS/Turnstile. AWS S3: failure-path MIME storage. Upstash: Redis DR tier. Self-hosted observability (VictoriaMetrics, VictoriaLogs, ManageEngine Firewall Analyzer) + Sentry error monitoring.
• Full sub-processor list: Security Policy §12 · Privacy Policy §5

Encryption

• In transit: TLS 1.2+ on all customer-facing traffic; mTLS/TLS on mail connectors (requireTLS + CA-signed cert, dedicated relays enforce client-cert auth); sslmode=verify-full on all DB connections.
• At rest: LUKS on all VMs; AES-256 cloud-managed encryption for databases and storage; application-layer field-level AES-256-GCM with KEK→per-region-DEK envelope encryption for credentials and secrets; 120-day key rotation with crypto-erasure.
• Key management: Azure Key Vault with soft-delete and purge protection; DKIM private keys in Key Vault (not DB); automated ≤90-day credential rotation (additive, no lockout window).
• Details: Security Policy §3 · TLS Policy · Encryption at Rest

Access control & authentication

• SSO (Google, Microsoft Entra ID), per-organization enterprise SSO (OIDC + SAML 2.0), magic-link email, optional passwords; TOTP MFA enforced by platform policy for organization admins and owners (not a per-user opt-in) — 15-day grace for new accounts, then admin-gated API routes return 403 until enrollment. Admins who sign in via enterprise SSO are exempt — the IdP's Conditional Access policies are the MFA authority.
• SCIM 2.0 provisioning: automated user lifecycle management via /api/scim/v2/Users — IdPs (Entra ID, Okta) can provision, update, and de-provision users; de-provisioned users have all sessions revoked immediately. See SCIM Setup Guide.
• Role-based access control with multiple privilege levels, enforced at every API route; sub-workspace isolation between parent and child workspaces.
• Tenant isolation: organization-scoped authorization on every route + a separate regional database per organization; RLS enabled as a database role-grant layer.
• Consent trail: policy acceptance recorded (version, timestamp, IP, user agent) at signup.
• Session management: idle timeout (~30 min), absolute lifetime (3h server ceiling), user-initiated "sign out all sessions", super-admin session termination, automatic revocation on MFA change and password reset.
• API key management: org API keys are SHA-256 hashed (never plaintext), 12 granular scopes, per-key CIDR IP allowlists, 90-day default expiry, revocable, full usage audit. See API Key Management.
• Console IP allowlist: per-org CIDR allowlist restricts console access to corporate egress IPs; applies to all roles including owner; super-admin recovery on lockout; Entra CA for federated tenants. See Console IP Allowlist.
• Details: Security Policy §4, §5, §7.6

Content & asset security

• Every uploaded image and saved HTML signature passes layered scanning: strict MIME allow-list (SVG blocked), magic-byte verification, size caps, HTML sanitization, URI-scheme allow-lists, URL reputation checks, homoglyph/IDN detection; continuous storage + retro-scanning of assets.
• Details: Security Policy §1

Data residency & disaster recovery

• Four data regions (US, India, EU, APAC) + a GDPR-isolated LTD tier; each with an in-region PostgreSQL replica and managed point-in-time recovery. Cross-region failover is opt-in and customer-controlled; EU/LTD data never crosses a border by default.
• RPO: ≤ 5 minutes (streaming replication); RTO: ≤ 15 minutes (in-region replica promotion) / ≤ 4 hours (full backup restore). Nightly encrypted platform backups (45-day retention, separate encryption key).
• Encrypted platform backups (regional + cold storage) with a separate encryption key; health-check-driven automated regional failover with state persisted independently of the monitored database.
• Details: Security Policy §2, §7 · Transfer Impact Assessment

Vulnerability management

• Snyk dependency scanning on every push + daily; container base images scanned and patched at build time; auto-fix PRs for patchable findings.
• Details: Security Policy §8

DDoS & web application security

• Cloudflare L3/L4/L7 DDoS mitigation, managed WAF (OWASP CRS), AI-bot blocking, edge rate limits on auth endpoints; origin lock (only edge traffic reaches the app); application-layer IP anomaly detection with adaptive Turnstile; documented DDoS playbook.
• Details: Security Policy §10

Audit logging & payments

• Every administrative action is audit-logged (actor, timestamp, details); retention for the account lifetime.
• Payments via Stripe / LemonSqueezy / Dodo / PayPal / Razorpay — AdtoSign stores no card data; all payment webhooks are signature-verified and idempotency-deduplicated.
• Details: Security Policy §9, §11

Incident response

• Vulnerability reports: 48-hour response, good-faith disclosure.
• Customer notification for incidents affecting customer data: within 72 hours (DPA §7, GDPR Art. 33(1), DPDPA s.8(6)), including nature, data affected, mitigation, and required actions. Breach register maintained per Art. 33(5).
• Details: Security Policy §14, §15 · Breach SLA

Compliance posture

• GDPR + DPDPA 2023 mapping pages; SOC 2 controls aligned with Trust Services Criteria (formal Type II attestation in progress); ISO/IEC 27001:2022 ISMS documentation complete with Statement of Applicability (93 Annex A controls); Microsoft AI Cloud Partner Program member.
• Details: Security Policy §13 · SOC 2 mapping

What we ask of you

Nothing beyond your normal mail-platform administration: if you enable the signature gateway, publish the SPF include and (optionally) the DKIM CNAME in your DNS. Both are one-line DNS records, and both are revocable by you at any time.