Security
Security controls for the Magnolia platform.
This page describes the technical and operational controls used to protect the Magnolia platform and its data.
- SOC 2 aligned — attestation in progress
- Security controls documented
- Independent testing scheduled annually
How we operate
Managed infrastructure
We use managed services for edge, compute, databases, and caches. Providers operate the underlying infrastructure, including redundancy, patching, and backups.
Operational monitoring
We use distributed tracing, structured logging, anomaly detection, and alerting to monitor the platform and investigate incidents.
Fail-closed operations
When a required safety control is unavailable, affected operations fail and return a retriable error rather than continue with incomplete validation.
Controls
Controls in place
Infrastructure
- Managed cloud services are used for infrastructure. The platform provider performs operating-system and runtime patching.
- Deployments use fresh containers built from reviewed commits. Production changes are made through the deployment pipeline.
- Rolling deployments are health-gated before traffic shifts to new instances.
- Internal services run on private networks and use pinned container image digests.
- A global edge terminates TLS and provides DDoS and web-application-firewall protections before requests reach the application.
- A dedicated egress identity allows approved third parties to allow-list platform traffic.
- Development, sandbox, and production use separate domains, credentials, third-party endpoints, and pipelines. Production secrets are scoped to the production pipeline.
Application and API
- Authentication is deny-by-default; unauthenticated endpoints must be explicitly declared.
- API keys are stored and logged as SHA-256 hashes. Raw keys are shown only when created.
- High-assurance integrations use Ed25519 request signing over the method, path, timestamp, nonce, and body digest to detect replay and modification.
- User and organization status is checked on each request.
- Inbound webhooks use HMAC-SHA256 verification with timing-safe comparison. We store received webhooks before processing them.
- Request rate limiting at the edge of the API, with standards-based limit headers.
- Runtime configuration is schema-validated at startup; missing or malformed values prevent the service from starting.
Encryption and data protection
- External communications use TLS 1.3 where supported, with TLS 1.2 as a compatibility fallback. Legacy protocols and weak ciphers are disabled.
- AES-256 or equivalent for all data at rest, including provider-managed database encryption and full-disk encryption on every business device.
- Application secrets are encrypted at rest and decrypted in process.
- Secrets are prohibited from source control and checked by automated scanning in the pipeline.
- A four-tier data-classification scheme and handling matrix govern access. Unclassified data defaults to confidential, and each category has an owner.
- Retention and disposal schedules define data handling. The highest tier requires cryptographic erasure or physical destruction, with disposal logged.
Access control and people
- Access is deny-by-default and requires formal approval. Elevated access requires two executive approvals.
- Multi-factor authentication is mandatory across production infrastructure, source control, email, and compliance systems, behind a single sign-on plane with passkeys prioritized.
- Sensitive infrastructure requires hardware-token MFA; SMS and email factors are not accepted.
- Access is reviewed quarterly across all systems, with additional monthly spot-checks for sensitive systems.
- Background checks precede production access. Certain roles receive enhanced screening and quarterly sanctions re-screening.
- Access is revoked within 24 hours of departure; sensitive-system access is removed by the last day, or within one hour for emergency offboarding.
- Every account is individually attributable. Shared accounts are prohibited for sensitive systems.
- Security awareness training is annual for all personnel, with policy acknowledgment on hire and annually thereafter.
Application integrity
- State-changing operations use idempotency controls. If the idempotency store is unavailable, the API returns a retriable 503.
- Changes that require multiple records are written in the same database operation.
- Append-only audit logs record unique event IDs, UTC timestamps, actors, affected entities, and outcomes. Access to logs is restricted.
Detection and response
- Distributed tracing is enabled for every request at 100% sampling.
- Logs are structured, trace-correlated, and include request, user, and job context.
- Infrastructure logs are shipped independently of the application.
- Automated anomaly detection monitors service behavior and identifies regressions.
- Monitors and deployment alerts are defined as code with the infrastructure they observe.
- The alerting pipeline is tested with deliberate error injection.
- Incident records include the triggering alert, timeline, ownership, resolution, and follow-up. Response uses dedicated channels with an out-of-band fallback.
Secure development
- Production changes require review by someone other than the author; repository rules enforce this requirement.
- Pull requests run blocking lint, type checks, unit and integration tests, end-to-end tests against sandbox environments, and static security analysis.
- Database migrations are tested on every pull request by applying the migration history to a fresh database and re-applying it. They are rehearsed against restored environment copies before merge.
- Threat modeling is required for features that handle sensitive operations, credentials, or key management.
- Sensitive-code rules require manual review of ambiguous validation and human confirmation before retrying signing operations.
- Dependencies use committed lock files and integrity verification. They are scanned continuously and updated weekly. CI actions are pinned to commit digests.
- Changes are classified before work begins. Sensitive signing and data-processing changes require dual approval, sandbox validation, and an author who is not the deployer.
- Critical production changes receive verification within one hour of deployment and enhanced monitoring for 72 hours.
Commitments
Response and recovery commitments
Security incident response
| Severity | Definition | Response |
|---|---|---|
| High | Major impact on operations or data | Immediate |
| Medium | Moderate impact; some systems or limited data affected | Within 2–4 hours |
| Low | Minor, minimal or no disruption | Within 1 business day |
When severity is uncertain, we initially use the higher classification. Medium and high incidents are escalated to the CEO when declared.
Vulnerability remediation
| Severity | Definition | Window |
|---|---|---|
| Critical | CVSS 9.0–10.0, or any severity touching signing infrastructure | 24 hours |
| High | CVSS 7.0–8.9 | 7 days |
| Medium | CVSS 4.0–6.9 | 30 days |
| Low | CVSS 0.1–3.9 | 90 days |
Vulnerabilities involving cryptographic libraries, key infrastructure, or signed-request construction are escalated to the CISO regardless of score. When immediate remediation is not possible, the CISO approves compensating controls and reviews them weekly until resolution.
Recurring verification
Continuity and recovery
The continuity plan accounts for a remote-first team, managed infrastructure, pre-provisioned interim leadership roles, and offline geographically protected key material for emergency recovery. It is exercised annually and updated after each exercise.
Governance
Ownership and oversight
Documented policies
Twenty governance documents cover information security, incident response, business continuity, access control, encryption and key management, secure development, change management, data handling, privacy, risk, and vendor management. They are reviewed at least annually; exceptions require written CISO approval.
Control ownership and evidence
Each control has an assigned owner and evidence collected in a compliance platform. Deficiencies are root-caused and tracked to resolution.
Risk management
A weighted risk methodology and measured control effectiveness inform a risk register with owners and review dates. The CISO and Compliance Officer report annually to the Board; newly identified high risks are escalated between reports.
Vendor oversight
Vendors are tiered by risk. Vendors handling keys, customer assets, or compliance functions are top-tier. Relevant contracts require 24-hour breach notification, audit rights, service levels, and certified data destruction on termination. Critical vendors are reviewed quarterly.
Separation of duties
No individual can initiate, approve, and deploy a sensitive production change. Sensitive signing operations require multi-signature authorization.
SOC 2
Our control environment is mapped to the SOC 2 Trust Services Criteria and informed by NIST and ISO 27001 practices. A SOC 2 attestation is in progress; no report has been issued.
Individual policy documents, security questionnaires, and — once issued — our SOC 2 report are available for review under NDA. Write to security@magnolia.financial. Live service availability is published at status.magnolia.financial.
Report a security issue
Email us the affected environment and steps to reproduce. Give us a reasonable opportunity to remediate before public disclosure. We do not pursue good-faith security research.
security@magnolia.financial