Security Architecture
Identity and access
Section titled “Identity and access”- Identity provider: Azure Active Directory is the authoritative identity provider for all employees and contractors.
- MFA: Multi-factor authentication is enforced for all production system access including the Azure portal, AWS console, GitHub, Pipedrive, and the zero-trust private network overlay.
- Production access: Limited to a documented Production Support Roster. All members complete background checks via a third-party provider before being added to the Roster.
- Access reviews: Performed by the CTO/CISO at least quarterly.
- Joiner / mover / leaver: Documented checklist with 24-hour revocation target (immediate for involuntary terminations).
Encryption
Section titled “Encryption”| Surface | At Rest | In Transit | Key Management |
|---|---|---|---|
| Operational database (PostgreSQL) | AES-256 (FIPS 140-2 compliant, service-managed) | TLS 1.2+ | Cloud platform |
| Secret store | AES-256 (HSM-backed where applicable) | TLS 1.2+ | Cloud platform |
| Cache | AES-256 | TLS 1.2+ | Cloud platform |
| WORM archival (object storage) | SSE-KMS | TLS 1.2+ | Account-owned KMS |
| Backup snapshots | AES-256 | TLS 1.2+ | Cloud platform |
| macOS endpoints | FileVault (XTS-AES-128, 256-bit key) | - | MDM-verified |
Customer-managed keys (CMK / BYOK) are not currently offered as standard. CMK can be enabled for the operational database tier on a per-deal basis on customer request.
Application secrets are stored in a centralized secret store accessed at runtime via short-lived managed identities. No plaintext secrets in application configuration, deployment history, Git history, or CI logs.
Network
Section titled “Network”- VNet isolation per environment. Dedicated subnets for application compute, managed services, database, and capture workloads.
- Private endpoints for secret store and cache. Public access denied.
- No public database endpoint - PostgreSQL is delegated to a private subnet.
- Static-IP egress via NAT gateway, allowlistable per downstream messaging platform.
- Administrative access via a zero-trust private-network overlay with identity-based ACLs and endpoint posture enforcement.
Application security
Section titled “Application security”- Branch-protected
mainwith mandatory pull requests, peer review, and CI pass before merge - Static application security testing (SAST) gated in CI on every pull request
- Dependency vulnerability scanning continuous on
main - Tag-based releases with manual confirmation gate (explicit
deploy productionphrase) - Infrastructure as Code (Bicep) with CI lint and what-if review on every PR
- Monthly internal penetration testing against staging and production
- Annual third-party assessment under the Google CASA program
Data segregation
Section titled “Data segregation”- Logical per-tenant segregation enforced at the application layer: every customer-data record is tagged with the owning team_id, and row-level access is gated by the authenticated user’s team membership.
- WORM archival uses an S3 prefix-per-tenant layout; sink writes are scoped to tenant prefixes by Kafka key.
Monitoring and logging
Section titled “Monitoring and logging”- Continuous infrastructure monitoring via centralized log analytics across all resource groups
- Severity-graded alerting with defined escalation paths to engineering on-call
- Application errors captured in a managed error-tracking platform with PII redaction enforced at the application layer
- Audit logs of all user and administrative actions. Audit logs cannot be altered or deleted by any user role, including Admin. Default retention indefinite, configurable per customer regulatory requirement.
Availability and disaster recovery
Section titled “Availability and disaster recovery”| Uptime target | 99.9% |
| RPO | 15 minutes |
| RTO | under 4 hours |
| Database backup | 35-day point-in-time recovery, encrypted, geo-redundant in production |
| WORM storage | Versioning + Object Lock Compliance mode + cross-region replication |
| DR exercise | Annual minimum |
Incident response
Section titled “Incident response”- Documented IR policy with severity tiers (SEV-1 / SEV-2 / SEV-3) and response targets (30 min / 2h / 1 business day)
- Customer notification within 72 hours of confirmed unauthorized access to or disclosure of customer data, consistent with GDPR Article 33 timing
- Post-incident review required for every SEV-1 and SEV-2 incident within 14 days of recovery
- Annual tabletop exercise at minimum
Personnel security
Section titled “Personnel security”- Background checks via Checkr for all employees and contractors before production access. In effect since April 2025.
- Signed Acceptable Use Policy at onboarding; re-acknowledged annually.
- Confidentiality and IP assignment agreements required of all personnel.
- Security Awareness Training within 30 days of start, and at least annually thereafter.
Asking deeper questions
Section titled “Asking deeper questions”Procurement and security review teams should request the NDA edition of the Trust Whitepaper, which includes named subprocessors and implementation specifics that are intentionally generalized on this public page.
Contact: Zeeshan Gulzar, CTO/CISO - zeeshan@commacompliance.com