Security

Baseline (STD01-12)

Every implementation under STD-01 must at minimum: authenticate and authorize process/service boundaries using approved platform identity mechanisms and least privilege; store secrets/keys/tokens/credentials only in approved secret management, passing references rather than values in domain records; encrypt sensitive data and secure evidence in transit and at rest; minimize Party, Payment Instrument, and external payload data in logs, queues, journal events, and operational views; use immutable/audited administrative actions for production suspension, configuration publication, manual correction, and privileged evidence access; and keep production and non-production identities, secrets, endpoints, data, and evidence physically/logically isolated.

Identity and Access controls

As the current-lean identity provider (DR-017, open — see Identity and Access): DragonPay's own Auth0-backed security controls (workforce/ operational identity only) would conform to the parent PE company's shared platform checklist, if confirmed: MFA via Universal Login policies, password policy with breach detection, brute-force protection via anomaly detection, RS256 token signing with cached JWKS validation, CORS whitelisting, dual session termination (local + Auth0 SSO) on logout, and gty: client-credentials validation so a user token can't be replayed against a machine-to-machine endpoint.

Data classification

Not yet a finished artifact. ENG01-17 calls for a concrete, field-level restricted/internal/public classification list — Party/Payment Instrument identifiers and account numbers as restricted; operational IDs and status enums as internal; published Product configuration as public — kept as a living reference engineers check new tables/logs/ telemetry against, operationalizing the STD01-12 principle above rather than leaving it as an unenforced guideline.

Secrets

Current lean: HashiCorp Vault (DR-011, open — ENG-01 §4, ENG01-22), injected into pods at startup rather than fetched by application code at request time; if confirmed, a cloud-native key-management service (Azure Key Vault under the current Cloud lean) would be narrowed to Vault's own auto-unseal mechanism.

What's not covered here yet

A formal SOC 2 certification program or enterprise access-governance tooling — explicitly out of scope for now (ENG-01 §14), sized for a team and customer base this stage doesn't have. This will be a real requirement before a production integration with a real credit union handling real member data goes live, and should be revisited well before that point, not left until it's urgent.