Data Security

Encryption

All data is protected with industry-standard encryption:

Infrastructure

• Hosted on AWS (US region)
• Application and database on isolated networks
• Regular security patches and updates
• DDoS protection via AWS Shield
• Automated monitoring and alerting

Data Handling

Here is what data we store and why:

Compliance

• GDPR compliant — data processing with legitimate interest / contract basis
• Users can request data export or deletion
• Data retention: active accounts retained indefinitely, deleted accounts purged after 90 days
• Sub-processors listed in our privacy policy

Access Control

• Role-based access control (Platform Admin, Org Admin, Learner)
• Organization-level data isolation (multi-tenant)
• SCIM token authentication for provisioning APIs
• Rate limiting on all public endpoints

Reporting Vulnerabilities

If you discover a security vulnerability, contact security@securecodinghub.com. We take all reports seriously and aim to respond within 48 hours.

Data classification at SecureCodingHub

We treat the data in our environment as falling into three practical buckets. Customer data is information that belongs to your organization and that your users entered or generated through the platform: account identifiers, learner email addresses, role assignments, training progress, scores against individual challenges, and stack preferences. This bucket is the one your DPO cares about and is the one we treat as the highest-sensitivity tier internally.

Operational telemetry is the second bucket. It covers request logs, anonymized performance metrics, error traces with personal identifiers stripped, and counters used to surface platform-wide reliability dashboards. This data is necessary to run the service safely and is retained on a shorter rolling window than customer data. The third bucket is challenge content itself — the vulnerable code samples, hints, and reference solutions that we author and ship to your users. That content is our intellectual property, not yours, and it is not commingled with your organization's records.

Retention windows differ accordingly. Active customer accounts are retained while the contract is in force. On account deletion we purge identifiable customer data on a 90-day clock, with the lag existing so that an accidental deletion can be reversed inside the window. Operational telemetry rolls off on a shorter cycle measured in weeks, not months. Full data inventory and retention specifics are available to customers under NDA via the request channel listed below, and are summarized for end users in the privacy policy.

How encryption is layered

Encryption on SecureCodingHub is not a single control — it is layered, and each layer assumes the others may fail. Data in transit between your users and the platform is protected by transport-layer encryption with modern cipher selection enforced at the load balancer, with weak protocols and downgrade-prone ciphers disabled. The same transport posture applies to traffic between application services and our managed datastores; nothing inside the production VPC moves in plaintext across a network boundary.

Data at rest is encrypted at the storage layer using the encryption services provided by our hosting platform, with key management handled by the same provider's managed key service rather than by application-level key material checked into our codebase. Backups inherit the same encryption posture as the primary store. We deliberately keep the description here at the policy level rather than publishing specific algorithms, key lengths, or rotation cadences on a public page, because publishing those values invites brittle dependencies and offers attackers a target list. The specifics are available under NDA for procurement reviews.

Tenant isolation is the third layer. Every record in the customer-data tier is scoped to an organization identifier, and that scoping is enforced in the data access layer rather than relying solely on application-level filters. The practical effect is that a query bug in one feature cannot accidentally expose another organization's data through the API, because the missing scope would surface as no results rather than as the wrong results. Role-based access within an organization is enforced by the same data-access layer, so a user's organization scope and role together determine which records are visible before any application-level filter runs.

Subprocessor and data residency posture

SecureCodingHub today is hosted in US regions only. That is a deliberate operational choice while we are at our current scale — running a single primary region simplifies our incident response, reduces the surface area auditors need to walk through, and keeps our subprocessor list short. For organizations evaluating us from outside the US, this is the single most important fact to surface to your data protection officer up front: data crosses a US border by design, and contractual safeguards including standard contractual clauses are made available to support that transfer.

If we add an EU-resident deployment in the future, the changes will be material rather than cosmetic. A separate primary region implies a separate set of subprocessors with EU-resident operations, a separate set of backup destinations, and an updated data processing addendum reflecting the new flow. We will not back-port existing organizations into a new region silently; any move would be an opt-in migration with notice and a defined cutover window. The current subprocessor list, the regional posture statement, and a current penetration test summary are available on request from security@securecodinghub.com. We answer vendor security questionnaires directly rather than only via shared trust portals, and we do not require the requesting party to be a paying customer to receive a current subprocessor list.