Security.

Internal security posture

Our internal posture is the floor we apply to every customer engagement. The same controls apply to Diviteb-only systems and to any environment we run on a customer's behalf unless their security is stricter.

• Identity — SSO via Google or Microsoft (customer's choice when we operate in their environment), hardware-key MFA mandatory on every account.
• Devices — Diviteb-managed laptops are encrypted at rest, MDM-enrolled, with EDR and remote wipe enabled. Personal devices are not used for customer work.
• Access — least-privilege, just-in-time elevation through our access-management tool; access reviewed quarterly and revoked the day a project ends.
• Networks — production access is gated behind VPN or per-application identity-aware proxy; SSH-only-with-keys, no password auth.

Customer engagements

We work in your repo, your cloud, your secrets. We don't replicate customer data into Diviteb-controlled systems. Per-engagement security requirements are codified in the SOW and DPA.

• Source control — we commit to your repo. Where required, we maintain a private mirror only for backup, deleted at engagement end.
• Secrets — we use your secrets manager (1Password, AWS Secrets Manager, Doppler, etc.). We don't paste secrets into chat, email, or our internal documents.
• Production access — scoped per engagement, JIT-elevated through your IAM, time-limited.
• Data — kept in your environment. Where we need a copy locally for development, it's anonymized or pseudonymized first.

Advertising accounts

We never ask for, share, or log in with a customer's personal social-media or advertising credentials.

• Access only through partner access in the customer's business portfolio or manager-account links, with the narrowest permissions the work needs.
• Two-factor authentication required on every Diviteb account that touches a customer ad account.
• Payment methods stay in the customer's name; we don't store card details.
• Access is reviewed monthly and removed the day an engagement ends.

Data protection

Data we process on a customer's behalf is governed by our DPA and the customer's instructions. Data we hold as a Controller (contact form submissions, newsletter subscribers, internal HR/finance) is encrypted at rest and in transit.

• In transit — TLS 1.2+ for all customer-facing surfaces, with HSTS preload on diviteb.com. Internal service-to-service uses mTLS where the platform supports it.
• At rest — AES-256 for object storage, native encryption for managed databases (Postgres TDE, S3 SSE).
• Backups — encrypted, rotated, and tested quarterly. Restore drills are documented and rehearsed.
• Key management — customer-managed keys (CMK) where the customer requires; otherwise platform-managed.

Secure SDLC

Every customer repository we touch runs the same baseline pipeline. We don't ship features that bypass it.

• Secret scanning on every commit; pushes that contain credentials are blocked at the pre-commit hook and re-checked in CI.
• Dependency scanning weekly via GitHub Dependabot or equivalent; critical findings triaged within 48 hours.
• Static analysis (SAST) — TypeScript-strict, ESLint security rules, language-appropriate scanners (Semgrep, CodeQL).
• Reviewed PRs — every merge to main needs at least one approval from a non-author senior engineer.
• Signed commits where the customer requires; otherwise GPG-signed by default for our own engineers.

Compliance

We've shipped customers through SOC 2, ISO 27001, HIPAA, and PCI audits as the technical partner. We're not SOC 2 certified ourselves yet; it's on our roadmap.

• Vendor security reviews — we'll respond to your standardized questionnaire (SIG, CAIQ, custom) within 5 business days.
• Penetration tests — we participate in customer-led pen tests and remediate findings within agreed SLAs (typically 30 days for critical).
• Sub-processors — listed in our DPA, updated with 30 days' notice before any change.
• Background checks — every Diviteb employee with customer-data access has passed a standard pre-employment background check.

Incident response

Our incident response process aims to detect, contain, eradicate, recover, and learn — in that order. We notify affected customers within 72 hours of confirming a security incident affects their data, regardless of regulatory requirement.

• Detection — automated alerts (Sentry, CloudTrail, GuardDuty) plus quarterly tabletop exercises.
• Containment — IR lead is paged; access is revoked or scoped down within 1 hour for critical incidents.
• Eradication and recovery — root cause traced, fix shipped, recovery validated against pre-incident baselines.
• Communication — affected customers notified inside 72 hours; status page (https://diviteb.com/status) updated as facts confirm.
• Post-incident — written post-mortem within 14 days, shared with affected customers; remediation tracked to completion.

Reporting a vulnerability

If you find a security issue on diviteb.com or in any of our public repositories, please report it through coordinated disclosure.

• Email [email protected] with a clear description, reproduction steps, and impact assessment.
• We acknowledge inside 24 hours and aim to triage inside 72.
• We commit to not pursuing legal action against good-faith research that respects user privacy and avoids destructive testing.
• We don't currently run a paid bug bounty, but we'll publicly credit you in our changelog (with consent) and send swag for material findings.

Logging and audit

Privileged actions in customer environments are logged at the platform level (CloudTrail, Cloud Audit Logs, etc.), retained for the period the customer requires, and shared on request. Internal Diviteb systems log access and changes to a centralized audit pipeline retained for 12 months minimum.

Sub-processors

Our current sub-processors are listed in our DPA. We give 30 days' notice before adding or replacing one.

Contact

Security questions, questionnaires, or vulnerability reports: [email protected].