Encryption, isolation, regional hosting:
secure by design.

Encryption at SDEN is concrete. In transit, every public endpoint terminates TLS 1.3 with modern cipher suites (ECDHE for key exchange, AEAD ciphers such as AES-GCM and ChaCha20-Poly1305), with HSTS preload requested where the domain ownership permits it. Internal service-to-service traffic inside our managed infrastructure is also TLS-encrypted; we do not assume a private network is a trusted network.

At rest, data is encrypted with AES-256 using cloud-provider-managed key services (AWS KMS, GCP KMS, or equivalent) by default, with customer-managed keys (CMK / BYOK) available on request for engagements where the threat model and regulatory context require it. Keys are rotated on a documented schedule and on demand following any access change. We do not ship products that store secrets in environment variables on a single VM and call it 'encrypted at rest': the distinction matters and we treat it as a code-review veto.

Authentication for SDEN staff is enforced through hardware-backed multi-factor (WebAuthn / FIDO2) for every account with access to production systems, customer data, or source code. Account provisioning runs through a documented joiner / mover / leaver process with quarterly access reviews. There is no shared credential to a production system; every action is attributable to a named human.

For the applications we ship, single sign-on through OIDC (Google Workspace, Microsoft Entra ID, Okta, Auth0) is the default option offered to enterprise clients. Where SSO is not available, password authentication is enforced with the OWASP-recommended hashing (Argon2id or scrypt), rate limiting at the credential stuffing layer, and mandatory multi-factor for any account with administrative scope. Role-based access control runs at least-privilege; the default permission for any new role is zero, and every grant is documented.

Audit logs are retained for a minimum of twelve months and are tamper-evident: the log stream itself is append-only and exported to an isolated destination so that a compromise of the application cannot retroactively rewrite the audit trail. PLACEHOLDER: confirm the configured retention window for each environment before publishing.

Multi-tenancy is where most SaaS security failures happen, and almost always because the isolation was enforced in application code rather than at the data layer. SDEN's default architecture enforces it at both. The tenant identifier propagates through the application as a required type (not an optional field), so a query that forgets to scope to a tenant is a TypeScript compile error rather than a runtime data leak. At the database, PostgreSQL row-level security policies enforce the same boundary: even a misbehaving service account cannot read across tenants without an explicit, audited override.

Where the threat model justifies the cost, we ship per-tenant encryption-at-rest keys so that a database-level compromise of one tenant's data cannot decrypt another's. Backups are similarly tenant-scoped, with the restore procedure documented and tested. The cross-tenant access matrix is integration-tested before every release: every endpoint is invoked with credentials from one tenant against records from another, and the expected refusals are asserted automatically.

Hosting jurisdiction is a data protection decision, not a procurement decision. Every product we ship is deployed in the region the customer requires, because the SOC 2 / CCPA / PIPEDA posture and the absence of cross-border transfer mechanisms are all simpler when the data does not leave its home region in the first place. The providers we use most often, AWS (us-east- / ca-central-), GCP (us- / northamerica-), and Azure across US, Canadian, and EU regions, have all signed Data Processing Agreements that we can pass through to clients without renegotiation.

Where a customer's threat model or regulatory context requires a region-locked deployment (US, Canada, or EU), we configure it to stay in that region; where a multi-region failover is required, we configure it with documented residency boundaries. We do not silently change the hosting region for a backup or a CDN edge without disclosure: the residency commitment in the DPA is the residency in production.

Backups are encrypted (AES-256), taken on a schedule appropriate to the data's recovery point objective (RPO), and stored in a region distinct from the primary so that a regional outage does not take the recovery with it. PLACEHOLDER: confirm the configured RPO and recovery time objective (RTO) per product before publishing externally. Typical defaults are RPO ≤ 24 hours and RTO ≤ 8 hours for the SaaS products SDEN runs.

Restore procedures are tested. A backup that has never been restored is a hope, not a recovery plan; we run periodic restore drills against a staging environment and document the result. When we hand a product over to a client, the restore runbook is part of the deliverable.

Secure-by-design is not a slogan at SDEN; it is a set of practices enforced through the same continuous integration pipeline that runs the test suite. At the design stage of every project, the threat model is written down: the assets we are protecting, the adversaries we are protecting them from, the trust boundaries through which data flows. The output drives the architecture decisions, the access control model, and the dependency choices.

In the pipeline, every pull request runs software composition analysis (SCA) against the dependency tree to catch known-vulnerable packages, static application security testing (SAST) against the code for the OWASP Top 10 patterns, and secret scanning to ensure credentials never land in the repository. Branch protection requires a passing build and a reviewer's approval before merge; signed commits are required on the main branch; container images are scanned and base images are pinned to a maintained tag with a documented refresh cadence.

Security vulnerabilities found in SDEN-built software can be reported confidentially to [email protected]; see the contact section below. We commit to a defined response window: acknowledgment within one business day, an initial triage within three business days, and coordinated disclosure timing agreed with the reporter before any public communication.

Internally, incidents follow a documented response process: a single incident commander is named at declaration, communication runs through a dedicated channel with timestamped updates, a customer-facing status update is published when the impact is customer-visible, and a written post-mortem is produced within ten business days of resolution. The post-mortem is blameless, names the contributing factors, and ships with action items tracked in the same backlog as feature work. Severe incidents trigger a notification to affected customers with the timeline and the remediation, in line with the applicable breach-notification window (CCPA, PIPEDA, and state laws) where applicable.