OpenClearWhat OpenClear itself does to meet each control objective, filed under the NIST SP 800-53 Rev. 5.1.1 controls it carries out. Several rely on the bank, its customers or whoever runs OpenClear to do their part: those are the complementary user entity controls (CUECs). It isn't legal advice (Compliance).
Inventory version 1.3. The same list, with each check's live status for your bank, is at
GET /api/v1/compliance/controls, and on the Controls page.
Reading the inventory
- Id:
OC-<family>-<nn>. Ids never change, and a withdrawn one is never reused. - NIST: the 800-53 Rev. 5 controls it carries out, the main one first.
- CSF 2.0: the NIST Cybersecurity Framework 2.0 subcategories that NIST's own mapping links to those 800-53 controls (by subcategory).
- Type: preventive stops something happening; detective shows that it happened; corrective puts it right.
- Nature: built in, always on; configurable, depends on a bank's setting. A configurable control relies on the CUEC that sets it.
- Checks: the tests of the control, each on the Controls page.
Access control
| Id | Control | NIST | CSF 2.0 | Type | Checks | Relies on | Where |
|---|---|---|---|---|---|---|---|
| OC-AC-01 | Permissions checked on every request. Every page, API call and background job checks the person's or API client's permissions, from their security group, before it reads or changes anything. | AC-3 Access Enforcement AC-6 Least Privilege |
PR.AA-05, PR.DS-10, PR.IR-01 | preventive, built in | privileged_accounts (live) |
B-AC-6-01 | Settings → Security groups; auth/permissions.py |
| OC-AC-02 | Access ends when a person leaves. Adding, changing and removing a person's access is recorded in the action log, and a deactivated person can't sign in or use a token from that moment. An identity provider can do the same through SCIM. If the bank chooses, OpenClear deactivates access after so many days without a sign-in and removes it after so many, telling the person a week before. | AC-2 Account Management AC-2(3) Disable Accounts AC-2(1) Automated System Account Management |
PR.AA-01, PR.AA-05, PR.DS-10, DE.CM-01, DE.CM-03 | preventive, built in | dormant_accounts (live)access_review (live)scim_sync (live) |
B-AC-2-01, B-AC-6(7)-01, B-AC-2(1)-01 | Users; Settings → Lockout and inactive accounts; the action log |
| OC-AC-03 | Customers see only their own. A business customer's people reach only their own customer's accounts, items and decisions, and never the bank's own permissions. A customer manages its own people and sign-on only when the bank allows it. | AC-3 Access Enforcement AC-4 Information Flow Enforcement AC-6 Least Privilege |
ID.AM-03, PR.AA-05, PR.DS-10, PR.IR-01, DE.CM-09 | preventive, configurable | customer_self_service (live)customer_dormant_users (live)customer_access_review (live) |
B-AC-2-02, C-AC-2-01, C-AC-6(7)-01 | A customer's page → Self-service; People |
| OC-AC-04 | Access by account. A customer's person can be limited to some of the customer's accounts; every list, item, decision, image, upload and export they reach is limited to those accounts. | AC-3 Access Enforcement AC-6 Least Privilege |
PR.AA-05, PR.DS-10, PR.IR-01 | preventive, configurable | — | C-AC-2-01 | People → Choose accounts; db/account_scope.py |
| OC-AC-05 | Segregation of duties. Conflicting permissions can't be combined in one security group, and whoever submitted an item can't decide its exception. Each bank chooses to warn or enforce; every breach attempt is logged. | AC-5 Separation of Duties | PR.AA-05 | preventive, configurable | segregation_of_duties (live)customer_sod (live) |
B-AC-5-01, C-AC-5-01 | Settings → Segregation of duties |
| OC-AC-06 | Dual control on decisions. When a bank turns dual control on, one person recommends a decision and a different person approves it. | AC-3(2) Dual Authorization AC-5 Separation of Duties |
PR.AA-05, PR.DS-10, PR.IR-01 | preventive, configurable | dual_control (live) |
B-AC-3(2)-01 | Settings → Dual control; Approvals |
| OC-AC-07 | Two people for settings changes. Turning a protection off (dual control, segregation of duties, lockout, password and inactivity rules, required sign-on, security event forwarding) always waits for a second admin; so do matching rules, scoring models, security groups, sign-on, API clients, webhooks and widening people's access when the bank asks, and a customer's own sign-on, API clients and new administrators when the bank or the customer asks. Tightening never waits; a switch turns on only while someone else can approve; with nobody else, a change takes effect after 24 hours as a critical security event. Every step is logged. | CM-3 Configuration Change Control CM-5 Access Restrictions for Change AC-3(2) Dual Authorization |
ID.RA-07, PR.AA-05, PR.DS-10, PR.PS-01, PR.IR-01, DE.CM-01, DE.CM-09 | preventive, configurable | two_person_changes (live)second_approver (live)sensitive_settings_protected (live) |
B-CM-3-01 | Settings → Dual control; Changes awaiting approval |
| OC-AC-08 | Support access only by grant. Platform staff reach a bank's data only through a grant the bank makes: named, with a reason and an end, read-only unless a second admin allows more, and never to decide. | AC-3 Access Enforcement MA-4 Nonlocal Maintenance AC-6(5) Privileged Accounts |
PR.AA-05, PR.DS-10, PR.IR-01 | preventive, built in | support_access_review (live)platform_staff (live) |
B-MA-4-01, H-AC-6(5)-01 | Settings → Support access |
| OC-AC-09 | Banks kept apart. Every query runs inside one bank's context, and on PostgreSQL row-level security refuses another bank's rows even if a query forgets to filter. | AC-4 Information Flow Enforcement AC-3 Access Enforcement |
ID.AM-03, PR.AA-05, PR.DS-10, PR.IR-01, DE.CM-09 | preventive, built in | — | — | db/tenancy.py; the RLS policies in migrations/ |
| OC-AC-10 | Sessions end. Sessions always end after an idle and an absolute timeout, whose lengths the bank sets, and a person can sign out their other devices. | AC-12 Session Termination SC-23 Session Authenticity |
PR.AA-03 | preventive, built in | — | — | Settings → Session timeouts |
| OC-AC-12 | ACH debits only from authorized originators. An ACH debit from an originator not on the account's authorizations becomes an exception for the customer to decide. | AC-3 Access Enforcement | PR.AA-05, PR.DS-10, PR.IR-01 | preventive, configurable | stale_ach_authorizations (live) |
C-AC-3-01 | ACH → Authorizations |
| OC-AC-13 | Two people at the service provider. Setting up a bank, platform staff roles, platform API keys and platform fees wait for a second of the platform's operators, and a request made with a platform API key waits for a person. Host attestations are prepared by one and accepted by another. The provider's own action log is chained and signed, and its security-relevant settings are watched until acknowledged. | CM-3 Configuration Change Control CM-5 Access Restrictions for Change AC-3(2) Dual Authorization AU-9 Protection of Audit Information |
ID.RA-07, PR.AA-05, PR.DS-10, PR.PS-01, PR.IR-01, DE.CM-01, DE.CM-09 | preventive, built in | installation_settings (live)provider_log (live) |
H-CM-6-01 | The operator view's Changes; the provider's action log |
Identification and authentication
| Id | Control | NIST | CSF 2.0 | Type | Checks | Relies on | Where |
|---|---|---|---|---|---|---|---|
| OC-IA-01 | Password policy and lockout. Passwords meet the bank's policy (length and the kinds of character required), and repeated failed sign-ins lock the account for a time, or until an administrator unlocks it, as the bank sets. | IA-5(1) Password-based Authentication AC-7 Unsuccessful Logon Attempts |
PR.AA-01, PR.AA-03 | preventive, configurable | password_policy (live) |
B-IA-5(1)-01 | Settings → Password policy; Settings → Lockout and inactive accounts |
| OC-IA-02 | Security keys and passkeys. People sign in with a FIDO2 security key or passkey as a second factor, which a bank or customer can require. | IA-2(1) Multi-factor Authentication to Privileged Accounts IA-2(2) Multi-factor Authentication to Non-privileged Accounts IA-2(8) Access to Accounts — Replay Resistant |
PR.AA-01, PR.AA-03 | preventive, configurable | admin_mfa (live)staff_mfa (live)customer_mfa (live)security_key_required (live) |
B-IA-2(1)-01, B-IA-2(2)-01, C-IA-2-01, B-IA-8-01 | My security; Settings → Password policy |
| OC-IA-03 | Single sign-on and SCIM. A bank, or a customer the bank allows, signs its people in through its own identity provider (OIDC or SAML), and can provision and remove them through SCIM. | IA-2 Identification and Authentication (Organizational Users) IA-8 Identification and Authentication (Non-organizational Users) AC-2(1) Automated System Account Management |
PR.AA-01, PR.AA-03, PR.AA-05, PR.DS-10, DE.CM-01, DE.CM-03 | preventive, configurable | scim_sync (live)customer_sso (live) |
B-AC-2(1)-01, C-AC-2(1)-01 | Settings → Sign-on; a customer's Sign-on |
| OC-IA-04 | Integration credentials. API clients authenticate with a secret kept only as a hash, or with a key pair (private_key_jwt, each assertion usable once), and can be limited to reading or to one customer. | IA-9 Service Identification and Authentication IA-5 Authenticator Management |
PR.AA-01, PR.AA-03 | preventive, built in | api_client_secrets (live)customer_api_client_secrets (live) |
B-IA-5-01, C-IA-5-01 | Settings → API clients |
| OC-IA-05 | Customers' sign-in set by the bank. The bank decides how each customer's people sign in: password and second factor, or the customer's own identity provider. | IA-8 Identification and Authentication (Non-organizational Users) | PR.AA-01, PR.AA-03 | preventive, configurable | customer_mfa (live) |
B-IA-8-01 | A customer's page → Sign-on |
Audit and accountability
| Id | Control | NIST | CSF 2.0 | Type | Checks | Relies on | Where |
|---|---|---|---|---|---|---|---|
| OC-AU-01 | Signed, chained action log. Every change is recorded with who, when, from where and what, each entry chained to the last and signed (ECDSA), so an entry can't be altered or removed unnoticed. | AU-2 Event Logging AU-3 Content of Audit Records AU-9(3) Cryptographic Protection AU-10 Non-repudiation AU-12 Audit Record Generation |
PR.DS-10, PR.PS-04, DE.CM-01, DE.CM-03, DE.CM-09 | detective, built in | audit_chain (live) |
— | Action log |
| OC-AU-02 | The chain verified. The action log's chain and signatures are verified daily and on request, and the Controls page shows the last result. | AU-9 Protection of Audit Information SI-7 Software, Firmware, and Information Integrity |
ID.RA-09, PR.DS-01, PR.DS-02, PR.DS-10, PR.PS-02, DE.CM-09 | detective, built in | audit_chain (live) |
— | Controls → Action log integrity |
| OC-AU-03 | Signed archives. Old action-log entries are archived to signed files before they leave the database, so they still verify. | AU-11 Audit Record Retention AU-9(3) Cryptographic Protection |
PR.DS-10, PR.PS-04 | preventive, built in | — | H-AU-9(2)-01 | services/audit_archive_service.py |
| OC-AU-04 | Security events delivered. Sign-ins, failures, lockouts, permission changes and control status changes become security events, delivered with retries to the bank's and the installation's SIEM. | AU-12 Audit Record Generation AU-6(1) Automated Process Integration SI-4 System Monitoring |
ID.RA-01, ID.IM-01, ID.IM-02, ID.IM-03, PR.DS-01, PR.DS-02, PR.DS-10, PR.PS-04, DE.CM-01, DE.CM-03, DE.CM-06, DE.CM-09, DE.AE-02, DE.AE-03 | detective, configurable | event_delivery (live) |
B-AU-6-01, H-AU-9(2)-01 | Settings → Security event forwarding |
| OC-AU-05 | Signed evidence export. For any period, a signed bundle of the version, rules and models in force, the chain's verification, breaches, changes, decisions and control status, which an examiner can check with the public key. | AU-7 Audit Record Reduction and Report Generation AU-11 Audit Record Retention |
PR.PS-04, RS.AN-03, RS.AN-06, RS.AN-07 | detective, built in | evidence_export (live) |
B-AU-11-01 | Controls → Export evidence |
System and communications protection
| Id | Control | NIST | CSF 2.0 | Type | Checks | Relies on | Where |
|---|---|---|---|---|---|---|---|
| OC-SC-01 | Secrets encrypted in the database. Secrets kept in the database (SSO keys, delivery credentials, plugin settings) are encrypted with AES-256-GCM under versioned keys, and re-encrypted when a key is rotated. | SC-28(1) Cryptographic Protection SC-12 Cryptographic Key Establishment and Management SC-13 Cryptographic Protection |
PR.DS-01, PR.DS-02, PR.DS-10 | preventive, built in | field_encryption (live)key_age (live) |
H-SC-12-01 | auth/crypto.py |
| OC-SC-02 | Encryption at rest stated. The host's statement of how disks and the database are encrypted is shown on the Controls page, which warns until there is one. | SC-28 Protection of Information at Rest | PR.DS-01 | detective, built in | storage_encryption (live) |
H-SC-28(1)-01 | Controls → Storage encryption |
| OC-SC-03 | Files signed. Every uploaded file is kept with its SHA-256 and a signature, and every webhook and evidence bundle OpenClear sends is signed. | SI-7(6) Cryptographic Protection SC-8 Transmission Confidentiality and Integrity |
ID.RA-09, PR.DS-01, PR.DS-02, PR.DS-10, PR.PS-02, DE.CM-09 | preventive, built in | — | — | An upload's page; webhooks |
| OC-SC-04 | Browser protections. Cookies are HTTP-only, and secure over HTTPS, which is marked with HSTS; every form carries a CSRF token; and a content security policy limits scripts to OpenClear's own. | SC-23 Session Authenticity SC-8 Transmission Confidentiality and Integrity SC-18 Mobile Code |
PR.DS-02 | preventive, built in | transport_security (live) |
H-SC-8(1)-01 | web/security.py |
| OC-SC-05 | Edge trusted only as configured. The caller's address is taken only from the configured edge's header, an edge secret can be required, and the Controls page shows the edge in front. | SC-7 Boundary Protection | PR.DS-01, PR.DS-02, PR.DS-10, PR.IR-01, DE.CM-01 | preventive, configurable | edge (live) |
H-SC-7-01 | Controls → Edge in front; docs/guides/edge.md |
| OC-SC-06 | Rate limits. Sign-ins, the API and expensive pages are rate limited per person, API client and address. | SC-5 Denial-of-service Protection AC-7 Unsuccessful Logon Attempts |
PR.AA-03, PR.IR-01, DE.CM-01 | preventive, built in | — | — | web/rate_limit.py |
| OC-SC-07 | Outbound connections checked. Webhooks and event destinations must be public addresses, checked when connecting, and are reported when not HTTPS. | SC-7 Boundary Protection SC-8 Transmission Confidentiality and Integrity |
PR.DS-01, PR.DS-02, PR.DS-10, PR.IR-01, DE.CM-01 | preventive, built in | integration_tls (live) |
B-SC-8-01 | Settings → Webhooks |
System and information integrity
| Id | Control | NIST | CSF 2.0 | Type | Checks | Relies on | Where |
|---|---|---|---|---|---|---|---|
| OC-SI-01 | Malformed files refused. X9.37, NACHA and delimited files go through hardened parsers that refuse malformed input quickly and cleanly; a corpus of bad files is run through them on every check. | SI-10 Information Input Validation | PR.DS-10 | preventive, built in | parser_hardening (live) |
— | Controls → Malformed-file handling |
| OC-SI-02 | Uploads checked row by row. Every upload row is validated and its result kept, failed rows can be corrected in the browser, and an upload can be backed out. | SI-10 Information Input Validation SI-7 Software, Firmware, and Information Integrity |
ID.RA-09, PR.DS-01, PR.DS-02, PR.DS-10, PR.PS-02, DE.CM-09 | corrective, built in | rejected_rows (live)file_reconciliation (live) |
C-SI-10-01, B-SI-7-01 | An upload's page |
| OC-SI-03 | Anomaly capture tested. A daily test injects known fraud patterns (duplicate serials, altered amounts, wrong accounts, malformed fields) into the bank's live rules in a dry run and records whether each was caught. | SI-4 System Monitoring CA-2 Control Assessments |
ID.RA-01, ID.IM-01, ID.IM-02, ID.IM-03, PR.DS-01, PR.DS-02, PR.DS-10, DE.CM-01, DE.CM-06, DE.CM-09, DE.AE-02, DE.AE-03 | detective, configurable | anomaly_capture (live) |
B-CA-7-02 | Model risk |
| OC-SI-04 | Replay before a change. A historical file can be replayed through today's rules in a dry run, showing how the result would differ, before a rule or model change is approved. | CM-4 Impact Analyses CA-2 Control Assessments |
ID.RA-01, ID.RA-07, ID.IM-01, ID.IM-02, ID.IM-03, PR.PS-01 | detective, built in | change_impact_replay (live) |
B-CM-4-01 | Model risk → Replay |
| OC-SI-05 | Decisions before the deadline. Each exception shows its deadline, reminders go out before the cutoff, and an undecided exception takes the account's default disposition. | SI-4 System Monitoring CP-2 Contingency Plan |
ID.RA-01, ID.IM-01, ID.IM-02, ID.IM-03, ID.IM-04, PR.DS-01, PR.DS-02, PR.DS-10, PR.IR-02, PR.IR-03, DE.CM-01, DE.CM-06, DE.CM-09, DE.AE-02, DE.AE-03, RC.RP-03, RC.CO-04 | corrective, configurable | sla (live)default_dispositions (live)customer_decision_timeliness (live) |
B-SI-4-01, B-CP-2-01, C-SI-4-01 | Exceptions; Settings → Reminders |
| OC-SI-06 | Decisions delivered to the core. Decisions go to the core through an outbox with retries, as files or calls, so none is lost if the core is down. | CA-3 Information Exchange | ID.AM-03, PR.DS-01, PR.DS-02, PR.DS-10 | corrective, built in | decision_delivery (live) |
B-CA-3-01 | Settings → Decision files |
| OC-SI-07 | The bank's unauthorized-debit statement form. Customers see the bank's own Written Statement of Unauthorized Debit form (Markdown, HTML or a PDF); the bank collects and keeps the signed statement its own way. | IR-6 Incident Reporting | PR.IR-03, RS.MA-01, RS.MA-02, RS.MA-03, RS.MA-04, RS.AN-06, RS.AN-07, RS.CO-02, RS.CO-03, RC.CO-03 | detective, configurable | wsud_form (live) |
B-IR-6-02, C-IR-6-01 | Settings → Unauthorized debit statement |
| OC-SI-08 | Reverse positive pay only as agreed. An account goes on reverse positive pay, where checks the customer doesn't return by the cut-off are paid, only as a protected change, and the accounts on it are listed for the bank to match against its agreements. | CA-3 Information Exchange AC-3(2) Dual Authorization |
ID.AM-03, PR.AA-05, PR.DS-01, PR.DS-02, PR.DS-10, PR.IR-01 | preventive, configurable | reverse_accounts_agreed (live) |
B-CA-3-02 | Customers → an account's Check review |
| OC-SI-09 | Checks verified at a branch. A teller platform verifies a check by the clearing rules before cash is paid at a branch, and records it cashed once, so the same check presented anywhere later is a duplicate. Its permission does nothing else, and probing for check numbers raises a security event. | SI-4 System Monitoring AC-6 Least Privilege |
ID.RA-01, ID.IM-01, ID.IM-02, ID.IM-03, PR.AA-05, PR.DS-01, PR.DS-02, PR.DS-10, DE.CM-01, DE.CM-06, DE.CM-09, DE.AE-02, DE.AE-03 | preventive, configurable | — | B-CP-2-02 | API: /api/v1/checks/verify and /cashed |
| OC-SI-10 | ACH monitoring summary. The evidence export summarizes the period's ACH debits by SEC code, exceptions, returns by reason code, unauthorized returns by originator, and decision times against their deadlines, for the bank's fraud-monitoring file and Rules audit. | SI-4 System Monitoring AU-6 Audit Record Review, Analysis, and Reporting |
ID.RA-01, ID.IM-01, ID.IM-02, ID.IM-03, PR.DS-01, PR.DS-02, PR.DS-10, PR.PS-04, DE.CM-01, DE.CM-06, DE.CM-09, DE.AE-02, DE.AE-03 | detective, built in | evidence_export (live) |
B-SI-4-02, B-IR-6-03 | Settings → Controls → Export evidence |
| OC-SI-11 | Checks decided within their return deadline. Each check's return deadline is worked out from the day it was presented, in the bank's banking days, and its decision deadline is never later than the cut-off on that day; a decision sent after it is flagged and raised as a security event. | SI-4 System Monitoring SI-10 Information Input Validation |
ID.RA-01, ID.IM-01, ID.IM-02, ID.IM-03, PR.DS-01, PR.DS-02, PR.DS-10, DE.CM-01, DE.CM-06, DE.CM-09, DE.AE-02, DE.AE-03 | preventive, built in | return_deadline (live) |
B-CA-3-04, B-SI-4-03 | Settings → Decision cut-off |
| OC-SI-12 | A leaving bank's data deleted, with a certificate. When a bank leaves, two of the service provider's operators start offboarding, which tells the bank to take its final export, and, after a wait, two approve deleting its data; it runs a day later unless stopped or put on legal hold, removes every row and file of the bank, and signs a certificate of what was deleted. | SI-12 Information Management and Retention MP-6 Media Sanitization |
ID.AM-07, ID.AM-08 | corrective, built in | — | H-MP-6-01, B-SI-12-01 | Platform → a bank's Offboarding |
| OC-SI-13 | A leaving customer's data deleted, with a certificate. Two bank administrators set a customer's last service day, and its people are told; after it, nobody there signs in and its accounts' items are refused; 90 days later, unless on legal hold, every row and file about the customer is deleted, the bank's action log is kept, and the bank keeps a signed certificate. | SI-12 Information Management and Retention MP-6 Media Sanitization AC-2 Account Management |
ID.AM-07, ID.AM-08, PR.AA-01, PR.AA-05, PR.DS-10, DE.CM-01, DE.CM-03 | corrective, built in | — | B-SI-12-02 | Customers → a customer's Offboarding |
| OC-SI-14 | Custom fields checked and complete. Each custom-field value is checked against its field's type, length, choices and uniqueness wherever it's written (forms, files, the API), a value is never shared with a customer unless its field is marked so, and OpenClear warns while a customer or account lacks a value for a required field. | SI-10 Information Input Validation SI-12 Information Management and Retention |
ID.AM-07, ID.AM-08, PR.DS-10 | detective, configurable | custom_fields (live) |
B-SI-12-03 | Settings → Custom fields; the lists' filter |
Configuration management
| Id | Control | NIST | CSF 2.0 | Type | Checks | Relies on | Where |
|---|---|---|---|---|---|---|---|
| OC-CM-01 | Production settings enforced. In production OpenClear refuses to start with the checked-in keys and secrets, placeholder legal text or incomplete storage settings, and the Controls page reports the settings in force. A change to the installation's security-relevant settings warns until one of the platform's operators acknowledges it. | CM-6 Configuration Settings | PR.PS-01, DE.CM-09 | preventive, built in | production_safety (live)installation_settings (live) |
H-CM-6-01 | Controls → Production safety; the operator view's Changes |
| OC-CM-02 | Versioned releases and migrations. Each release is versioned with a changelog, its database migrations upgrade and downgrade, and the running version is published. | CM-3 Configuration Change Control SI-2 Flaw Remediation CP-10 System Recovery and Reconstitution |
ID.RA-07, ID.IM-01, ID.IM-02, ID.IM-03, PR.PS-01, PR.PS-02, PR.IR-03, DE.CM-01, DE.CM-09, RC.RP-01, RC.RP-02, RC.RP-05 | preventive, built in | software_currency (live) |
H-SI-2-01 | /openapi.json; CHANGELOG.md |
| OC-CM-03 | What's running is recorded. The evidence export records the version, the plugins and models in force with their digests, and the outside services turned on. | CM-2 Baseline Configuration CM-8 System Component Inventory |
ID.AM-01, ID.AM-02, PR.PS-01 | detective, built in | outside_services (live) |
B-SA-9-01 | Controls → Export evidence |
Assessment and monitoring
| Id | Control | NIST | CSF 2.0 | Type | Checks | Relies on | Where |
|---|---|---|---|---|---|---|---|
| OC-CA-01 | Controls checked continuously. Each control is checked when the Controls page or API is read and hourly; a change of status becomes a security event. | CA-7 Continuous Monitoring | ID.RA-01, ID.RA-07, ID.IM-01, ID.IM-02, ID.IM-03, DE.CM-01, DE.CM-02, DE.CM-03, DE.CM-06, DE.CM-09, DE.AE-02, DE.AE-03 | detective, built in | control_response (live) |
B-CA-7-01 | Controls |
| OC-CA-02 | Health and jobs reported. /health reports whether the database answers, and each scheduled job's last run is kept. | CA-7 Continuous Monitoring SI-4 System Monitoring |
ID.RA-01, ID.RA-07, ID.IM-01, ID.IM-02, ID.IM-03, PR.DS-01, PR.DS-02, PR.DS-10, DE.CM-01, DE.CM-02, DE.CM-03, DE.CM-06, DE.CM-09, DE.AE-02, DE.AE-03 | detective, built in | scheduled_jobs (live) |
H-SI-4-01 | /health |
| OC-CA-03 | Regulatory pages kept current. Each page mapping OpenClear onto a law, rule or guidance says when it was last checked against its sources, and a check warns when one is more than a year old. | CA-7 Continuous Monitoring | ID.RA-01, ID.RA-07, ID.IM-01, ID.IM-02, ID.IM-03, DE.CM-01, DE.CM-02, DE.CM-03, DE.CM-06, DE.CM-09, DE.AE-02, DE.AE-03 | detective, built in | regulatory_currency (live) |
— | Controls; docs/compliance/ |
Incident response
| Id | Control | NIST | CSF 2.0 | Type | Checks | Relies on | Where |
|---|---|---|---|---|---|---|---|
| OC-IR-01 | Incident notices to each bank. The installation's operator sends incident and maintenance notices to the banks affected: each is emailed to the bank's incident contacts (or its CEO and CIO) and shown to its administrators until one acknowledges it, with sending and acknowledging in the bank's action log and raised as security events. | IR-6 Incident Reporting IR-4 Incident Handling |
ID.IM-01, ID.IM-02, ID.IM-03, PR.IR-03, DE.AE-02, DE.AE-03, DE.AE-06, DE.AE-08, RS.MA-01, RS.MA-02, RS.MA-03, RS.MA-04, RS.MA-05, RS.AN-03, RS.AN-06, RS.AN-07, RS.AN-08, RS.CO-02, RS.CO-03, RS.MI-01, RS.MI-02, RC.RP-01, RC.RP-02, RC.RP-06, RC.CO-03, RC.CO-04 | corrective, built in | incident_contacts (live) |
H-IR-6-01, B-IR-6-06, B-IR-6-07 | Platform → Incidents; the banner on every page |
| OC-IR-02 | Incident contacts kept current. Each bank names its incident contacts, with its CEO and CIO as the fallback, and confirms them yearly; changing them is a high security event. | IR-6 Incident Reporting | PR.IR-03, RS.MA-01, RS.MA-02, RS.MA-03, RS.MA-04, RS.AN-06, RS.AN-07, RS.CO-02, RS.CO-03, RC.CO-03 | preventive, configurable | incident_contacts (live) |
B-IR-6-05 | Settings → Incident contacts |
Contingency planning
| Id | Control | NIST | CSF 2.0 | Type | Checks | Relies on | Where |
|---|---|---|---|---|---|---|---|
| OC-CP-01 | Recovery objectives stated. The host's recovery time and recovery point objectives and the date of its last restore test are shown on the Controls page, which warns until they're recorded or once the test is over a year old. | CP-2 Contingency Plan CP-4 Contingency Plan Testing |
ID.IM-01, ID.IM-02, ID.IM-03, ID.IM-04, PR.IR-02, PR.IR-03, RC.RP-03, RC.CO-04 | detective, built in | recovery_objectives (live) |
H-CP-2-01, H-CP-9-01, B-CP-2-03 | Controls → Recovery objectives stated |
Built from docs/compliance/controls.md in the OpenClear repository. Last changed October 28, 2026.