NIST Cybersecurity Framework (CSF 2.0) — Self-Alignment

The NIST Cybersecurity Framework (CSF) 2.0 organizes a security program into six functions — Govern, Identify, Protect, Detect, Respond, Recover. This page maps OWL's security controls to those functions. It is a self-alignment in the same spirit as our secure-development (SSDF) page — not a certification.

Part of NDEVR's compliance & conformity program · Security contact: security@ndevr.org.

The CSF has no certification. NIST does not certify conformance to the CSF — it is a voluntary framework for organizing and communicating security posture. So this page is an honest self-mapping, not a claim of any "NIST certification." Where a function is still maturing, we say so.

1. Mapping OWL to the CSF 2.0 functions

CSF 2.0 functionHow OWL aligns
Govern (GV)This published compliance program is our security governance surface — documented posture across cryptography, secure development, privacy, and sub-processor governance, kept honest as status changes. Formal, periodically-reviewed written policies (risk register, defined review cadence) are a practice in progress.
Identify (ID)Dependency and component inventory via a CycloneDX SBOM; data classification separates provider-blind CSD payloads from SSD processing, account, authorization, billing and network records, and plaintext public Sites, as documented in the privacy policy.
Protect (PR)CSD AES-256 content encryption with authenticated AES-256-GCM for new key wraps (existing CBC wraps remain readable and are re-wrapped on read) and P-256 ECIES (cryptography); identity & access via per-folder / share-link keys checked from ancestors; OPAQUE web authentication with rate limiting and failed-login lockout; TLS with the platform's trusted roots; HTTP security response headers; secure defaults. SSD is a provider-trust mode; user-held recovery preserves the CSD boundary.
Detect (DE)An administrative audit log of privileged actions, plus request and failed-login logging that supports brute-force / anomaly detection. Centralized SIEM with automated alerting is a practice in progress.
Respond (RS)A published coordinated vulnerability disclosure policy and security advisories feed; Ed25519-signed updates provide a path to ship fixes with integrity (and to signal out-of-maintenance / end-of-support). A formal, exercised incident-response runbook with defined roles is a practice in progress.
Recover (RC)Content at rest is encrypted and backed up (residual copies purged on the normal backup cycle); account/key recovery is available through a user-held recovery key (privacy policy); the operator stores only an encrypted envelope and cannot open the account key. Documented, regularly tested restore / BCDR procedures with stated RTO/RPO are a practice in progress — we do not claim a tested DR plan we have not exercised.

2. Implementation tiers

The CSF describes optional Implementation Tiers (Partial → Risk Informed → Repeatable → Adaptive) that characterize how rigorous and repeatable an organization's practices are. We have not formally assessed OWL against a tier. Informally, our technical controls (Protect) are strong and largely repeatable, while our process controls (governance cadence, tested recovery, formal IR) are earlier in maturity — so we decline to claim a specific tier rather than overstate one.

3. Scope & honesty

This is a point-in-time self-alignment of OWL's design and implemented controls. It is not an audit, and the CSF offers no certification to hold. The "in progress" items above are real and are part of our roadmap. If you identify a gap, our coordinated vulnerability disclosure program is the place to report it.