Security at SecureCodingHub

All data at rest is encrypted using AES-256 encryption. Database volumes, backups, and file storage are all encrypted with keys managed through a dedicated key management service.

All communications between clients and our servers use TLS 1.3. We enforce HTTPS across all endpoints with HSTS headers and certificate transparency monitoring.

Customer data is logically isolated at the application layer. Each organization's data is segregated with strict access controls, ensuring no cross-tenant data leakage.

Enterprise customers can integrate with their identity provider using SAML 2.0 single sign-on. We support all major IdPs including Azure AD, Okta, and OneLogin.

MFA support adds an additional layer of security to user accounts. We support TOTP-based authenticator apps for second-factor verification.

Sessions are cryptographically secured with short-lived tokens, automatic expiration, and revocation capabilities. Inactive sessions are terminated after a configurable timeout period.

We conduct regular third-party penetration tests of our infrastructure and application. Findings are triaged, prioritized, and remediated according to severity.

Our CI/CD pipeline includes automated dependency scanning and software composition analysis. Known vulnerabilities in third-party libraries are flagged and addressed promptly.

We maintain a responsible disclosure program for security researchers. If you discover a vulnerability, please report it to us and we will work with you to resolve it.

We collect only the data necessary to provide our services. We do not collect unnecessary personal information and we do not sell user data to third parties.

Data is retained only for as long as needed to fulfill the purposes for which it was collected. When data is no longer required, it is securely deleted or anonymized.

Users can request deletion of their account and associated data at any time. We process deletion requests promptly and confirm completion within 30 days.

Every change to production passes through a pull request review with at least one engineer outside the author's immediate working pair. CI runs unit, integration, and security checks on every push. Production deploys go through a separate approval step. Emergency changes follow a documented break-glass procedure with retrospective review the same week. Infrastructure changes are managed as code and reviewed under the same workflow as application code.

Software composition analysis runs on every pull request and again on a nightly schedule against the main branch. Critical and high severity advisories trigger an alert to the on-call engineer with a target remediation window measured in days, not weeks. Medium and low advisories are batched into a weekly review. Container base images are rebuilt on a fixed cadence so transitive operating system patches reach production without requiring application changes.

The incident response plan defines four severity tiers, escalation paths, and a single point of accountability per incident. The first responder is responsible for containment and customer communication while a dedicated investigator works the technical trail. Post-incident reviews are blameless and produce a written record with action items tracked to closure. The plan is rehearsed at least twice a year against scripted scenarios so the muscle memory exists before a real incident.

If your security team finds something during a contract pentest, an internal review, or routine use of the product, report it directly to our security team rather than discussing it publicly first. We will acknowledge within two business days, share a tracking identifier, and provide status updates until the issue is closed. We treat coordinated disclosure as a partnership.

Customer administrators control role assignment within their tenant. The principle we encourage is the same one we apply internally: assign the narrowest role that lets a user do the work, and review the assignments on a regular cycle. Administrative access in particular should be limited to a small named group, and that group should be audited as people change roles inside your organization.

When a person leaves your organization, deactivating them in your identity provider should propagate through SCIM to remove access from the platform. We strongly recommend SCIM-based provisioning over manual user management for any organization above thirty seats. If you cannot adopt SCIM today, an account-level off-boarding checklist with a named owner is the next best control.

A status page covering platform availability and degraded-service incidents. A list of sub-processors. The current data processing addendum. This security page itself. Once SOC 2 Type II is complete, the report will be available under NDA on request through your account contact. Material policy updates that affect customers are announced through your account contact rather than buried in a changelog.

Internal network architecture diagrams, detailed authentication flows, the specific tooling our security team uses, key rotation schedules at the level of individual keys, and the names and roles of staff on the security team. Any of these can be reviewed under NDA when the conversation requires it — for example during a procurement-led security review — but they do not belong on a public page. Publishing them would lower the cost of a targeted attack without giving any customer a real benefit.