Monitor and Review: A Reasonable Basis That the Technology Program Is Operating

In plain language

Regulators do not ask whether you have policies. They ask how you know the policies are working. This page is the checklist for answering that — every check from every library section in one list, each paired with the artifact that answers it, plus the configuration state someone should confirm in the live environment rather than in a document.

An annual review under Advisers Act Rule 206(4)-7, a supervisory control report under FINRA Rule 3120, an investor due diligence response, and an examination request all ask a version of the same question: how do you know this is working?

This page aggregates every check from every Compliance Library section, in each case paired with the artifact that answers it. It is the backward-looking companion to scheduled actions, which is the forward-looking calendar.

How to use it

Work the checklist in one sitting and score each row three ways rather than two:

Yes, and here it is. Name the artifact and its date. This is the only answer that produces a basis.
Not applicable, because. Record the reason. A firm with no covered accounts has no Reg S-ID checks to pass, but it does need the determination on file.
No. Record it as a finding with an owner and a date. An open, owned gap is a defensible position; an unnoticed one is the finding an examiner makes for you.

Two properties turn a completed checklist into evidence. Everything is dated, and recurrence is visible — the previous version of each artifact still exists. One access review is a task. Two consecutive access reviews are a program.

What weak reviews have in common

They cite the policy instead of citing output. The policy is the thing being tested, so it cannot be the evidence.
They confirm configuration from a settings page rather than from behaviour. A retention setting of 365 days is not the same as a log search that returns an event from eleven months ago.
They record only exceptions, leaving the periods with no findings looking like periods with no review.
They stop at “flagged for removal” and never show the removal completed.
They are performed entirely by the party that operates the controls, which produces an opinion rather than an independent basis.

The checklist

49 checks aggregated from 9 library sections. Each names the artifact that answers it, because an examiner's follow-up question is almost always "show me."

Regulation S-P: Safeguards, Incident Response, and the Notification Clocks

The customer information inventory has been reviewed within the last quarter and reflects systems added since the last review.
Evidence: Dated inventory with reviewer name; change log or ticket references for additions.
mon.reg-s-p.inventory-current
The written incident response program exists, is current, and was approved by someone with authority to approve it.
Evidence: Signed or minuted approval with a date; version history.
mon.reg-s-p.ir-program-approved
The customer notification path has been exercised at least once in the last twelve months, including the scope determination and the approval step.
Evidence: Tabletop memo naming participants, scenario, decisions, and timing.
mon.reg-s-p.notice-path-exercised
Service providers with access to customer information are under agreements carrying the 72-hour notification obligation, with any gaps tracked to an owner and a date.
Evidence: Vendor register showing clause status; exception list with remediation owners.
mon.reg-s-p.vendor-clauses-in-place
Encryption is enforced rather than available on the systems that hold customer information.
Evidence: Configuration export or policy screenshot showing enforcement and the exception list.
mon.reg-s-p.encryption-enforced

Advisers Act Compliance and Cybersecurity: Rule 206(4)-7 and the Technology Program

The most recent annual review is complete, dated within the last twelve months, and identifies the person who performed it.
Evidence: Annual review memo with date, author, scope, findings, and remediation status.
mon.advisers-act.review-completed-dated
The annual review cites at least one test result rather than only describing policy text.
Evidence: Referenced artifacts: access review output, restore test log, phishing simulation results, patch compliance report.
mon.advisers-act.review-tested-something
The risk assessment names the systems currently in use, including anything added in the last year.
Evidence: Risk assessment dated within twelve months, cross-checked against the asset inventory.
mon.advisers-act.risk-assessment-matches-environment
Every open control exception has a named owner and a review date that has not passed.
Evidence: Exception register export.
mon.advisers-act.exceptions-owned
Security awareness training is complete for all staff, with the non-completions identified and followed up.
Evidence: Per-person completion report.
mon.advisers-act.training-complete

Books and Records: Electronic Retention Under Rule 17a-4 and Rule 204-2

A records production has been tested within the last quarter, with the elapsed time and any retrieval failures recorded.
Evidence: Production test log: requester, scope, elapsed time, gaps found.
mon.books-records.production-tested
Every communication channel in use is either captured by the archive or affirmatively blocked, with no channel in an undecided state.
Evidence: Channel inventory showing capture or block status per channel, dated.
mon.books-records.channels-accounted-for
Configured retention periods match the retention schedule, including for categories that are longer than the default.
Evidence: Retention policy export compared against the written schedule.
mon.books-records.retention-configured
The most recent archive reconciliation found no unexplained gaps, or the gaps found are tracked to a fix.
Evidence: Reconciliation report with variance explanations.
mon.books-records.archive-gaps-zero
The firm has documented which 17a-4 electronic recordkeeping option it relies on and can show it meets that option's conditions.
Evidence: Written determination plus the supporting vendor attestation or configuration evidence.
mon.books-records.recordkeeping-option-documented

FINRA Supervision and Cybersecurity: Rule 3110 and Broker-Dealer Technology Controls

Supervisory reviews for the last three periods exist and are evidenced, including periods when nothing was escalated.
Evidence: Review logs showing reviewer, date, sample, and disposition.
mon.finra-supervision.reviews-evidenced
The written supervisory procedures name the actual systems in use today.
Evidence: WSP section compared against the system inventory, dated.
mon.finra-supervision.wsp-names-systems
The most recent supervisory control report was produced within the last twelve months and reached senior management.
Evidence: Annual report with distribution record.
mon.finra-supervision.3120-report-current
The business continuity plan was tested rather than reviewed, with the test result and any failures recorded.
Evidence: Test plan and results, including restore or failover timings.
mon.finra-supervision.bcp-tested
Every office, including remote locations within the inspection scope, has been inspected within its stated cycle.
Evidence: Inspection schedule with completion dates and findings.
mon.finra-supervision.locations-inspected

Regulation S-ID: Identity Theft Red Flags, at a High Level

The firm either has a current written identity theft prevention program or a recorded, reasoned determination that it maintains no covered accounts.
Evidence: Program document with approval record, or the dated determination memo and supporting risk assessment.
mon.reg-s-id.program-or-determination-exists
The program has been updated within the last twelve months and the update reflects something that changed.
Evidence: Version history showing substantive changes, not only a date change.
mon.reg-s-id.program-updated
Technical red flag alerts are routed to a monitored queue and the last period's alerts have recorded dispositions.
Evidence: Alert queue export with dispositions.
mon.reg-s-id.alerts-reach-a-person
A sample of recent disbursements shows out-of-band verification was performed and recorded.
Evidence: Sampled transaction records with verification notes.
mon.reg-s-id.disbursement-verification-followed
The most recent report to the board or senior management exists, is dated, and covers effectiveness, incidents, and recommended changes.
Evidence: Report with distribution or minute reference.
mon.reg-s-id.board-reporting-done

Vendor and Service-Provider Oversight for Regulated Financial Firms

The vendor register was reconciled against payables and connected applications within the last quarter, and the additions found were triaged.
Evidence: Reconciliation output with the delta list and dispositions.
mon.vendor-oversight.register-reconciled
Every tier-one vendor has a review dated within the last twelve months that records what was examined.
Evidence: Register export showing last-review dates; review notes referencing report period, scope, and exceptions.
mon.vendor-oversight.tier-one-reviewed
Contract notification status is recorded for every in-scope vendor, with gaps assigned to an owner and a target date.
Evidence: Register field plus the exception list.
mon.vendor-oversight.notification-clauses-tracked
No vendor or support account remains enabled for a provider the firm no longer uses.
Evidence: Account list cross-checked against the register's active vendors.
mon.vendor-oversight.no-orphan-vendor-access
For vendors terminated in the period, access revocation and data return or destruction were confirmed in writing.
Evidence: Termination records with the provider's confirmation.
mon.vendor-oversight.offboarding-confirmed

Access Control and MFA for RIAs, Broker-Dealers, and Funds

The current MFA coverage report has been reconciled to the exception register, and every unenrolled identity is either approved or in remediation.
Evidence: Coverage report and exception register from the same date.
mon.access-mfa.coverage-reconciled
The last access review resulted in identifiable changes, and the removals it called for were actually made.
Evidence: Review output plus the tickets or logs showing the removals completed.
mon.access-mfa.reviews-produced-removals
Every departure in the period had access revoked within the firm's stated window, including mobile devices and vendor-side accounts.
Evidence: Departure list matched to revocation timestamps.
mon.access-mfa.leavers-revoked
No account holds permanent administrative privilege outside the approved break-glass set, and the break-glass accounts' use is alerted on.
Evidence: Privileged role assignment export; break-glass usage alert history.
mon.access-mfa.no-standing-admin
Authentication paths that bypass multi-factor enforcement are blocked, verified by testing rather than by reading the policy.
Evidence: Sign-in log filtered for legacy protocols showing no successes, or the block policy with a test result.
mon.access-mfa.legacy-auth-closed
Every service account, API key, and shared mailbox has a named owner and a current justification.
Evidence: Non-human identity inventory with owners and last-confirmed dates.
mon.access-mfa.non-human-identities-owned

Incident Response and Exam Evidence for Financial Firms

A written incident response program exists, covers assessment, containment, and notification, and carries a dated approval.
Evidence: Program document with approval record and version history.
mon.incident-response.program-written-and-approved
A tabletop has been run within the last twelve months and produced findings that were acted on.
Evidence: Tabletop memo with participants, scenario, decisions, and the remediation items it generated.
mon.incident-response.tabletop-within-year
Log retention has been verified by searching for an event at the far end of the stated window, not by reading the configured setting.
Evidence: Search result showing an event at or near the retention boundary, dated.
mon.incident-response.log-window-verified
A restore has been completed within the last quarter, with elapsed time recorded and failures noted.
Evidence: Restore test record including what was restored and how long it took.
mon.incident-response.restore-tested
The program names the person who decides on customer notification, and a backup, with contact details that work when firm email does not.
Evidence: Program section naming roles; current out-of-band contact list.
mon.incident-response.notification-decision-owner
The standing exam evidence file holds the current version of each core artifact, each dated within its own review cycle.
Evidence: File index with artifact names, versions, and dates.
mon.incident-response.exam-file-current
Every incident in the period has a written post-incident review, including the ones that were contained without client impact.
Evidence: Incident log cross-referenced to review documents.
mon.incident-response.incidents-reviewed

Private Fund and PE Adviser Technology Notes

The operational due diligence pack is current and each artifact in it is dated within its own review cycle.
Evidence: Pack index with artifact dates.
mon.private-funds.ddq-pack-current
No closed transaction retains active external access to its deal room.
Evidence: Data room access report by transaction, with closure dates.
mon.private-funds.closed-deal-access-removed
Every external participant with access to firm or fund data authenticates with multi-factor authentication and an attributable identity.
Evidence: Guest and external user list with authentication method.
mon.private-funds.external-users-mfa
No shared administrative credential or identity tenant spans the adviser and a portfolio company.
Evidence: Identity architecture diagram plus privileged account export per tenant.
mon.private-funds.boundary-intact
Fund-level records subject to retention live in a system with retention configured, rather than only on a file share.
Evidence: Record category mapping to systems with retention settings.
mon.private-funds.fund-records-in-system
A sample of recent capital calls and distributions shows out-of-band verification and dual authorisation were performed.
Evidence: Sampled transaction approvals with verification records.
mon.private-funds.disbursement-controls-followed

Configuration state to confirm

53 configuration touchpoints from across the library. A review has a reasonable basis when someone has actually looked at each of these in the live environment, not only in a policy document.

Configuration rule	Applies to	Section	config-id
Every system, share, mailbox, and vendor that can reach customer information appears in one inventory with a named owner and a recorded last-review date.	Asset and data inventory	Regulation S-P: Safeguards, Incident Response, and the Notification Clocks	`cfg.reg-s-p.customer-info-inventory`
Customer information is encrypted where it is stored and whenever it moves outside the firm's network, including email containing account numbers.	Endpoints, file storage, email gateway	Regulation S-P: Safeguards, Incident Response, and the Notification Clocks	`cfg.reg-s-p.encryption-at-rest-and-in-transit`
Access to systems holding customer information is logged, and those logs are retained long enough to reconstruct who saw what during an incident investigation.	Identity provider, file storage, line-of-business applications	Regulation S-P: Safeguards, Incident Response, and the Notification Clocks	`cfg.reg-s-p.access-logging-retained`
Alerts that would indicate unauthorized access to customer information route to a monitored queue with a defined response time, not to an individual's inbox.	SOC / monitoring platform	Regulation S-P: Safeguards, Incident Response, and the Notification Clocks	`cfg.reg-s-p.breach-detection-alerting`
For each in-scope service provider, the firm records the channel a 72-hour breach notice would arrive on and who monitors it outside business hours.	Vendor register	Regulation S-P: Safeguards, Incident Response, and the Notification Clocks	`cfg.reg-s-p.vendor-notification-contact`
Media and devices that held customer information are wiped or destroyed to a documented standard before leaving the firm's control.	Endpoint lifecycle, decommissioning process	Regulation S-P: Safeguards, Incident Response, and the Notification Clocks	`cfg.reg-s-p.secure-disposal`
One current version of each technology policy is the version of record, stored where the CCO controls it, with superseded versions retained rather than overwritten.	Document management / compliance repository	Advisers Act Compliance and Cybersecurity: Rule 206(4)-7 and the Technology Program	`cfg.advisers-act.policy-of-record`
The artifacts the annual review depends on — access reviews, restore tests, training records, patch status — are produced on a schedule and stored somewhere the CCO can retrieve them without asking IT.	Reporting and evidence store	Advisers Act Compliance and Cybersecurity: Rule 206(4)-7 and the Technology Program	`cfg.advisers-act.review-evidence-collection`
Accepted technology risks and control exceptions are recorded with an owner, a reason, and a review date, instead of existing only as an understanding.	Risk / exception register	Advisers Act Compliance and Cybersecurity: Rule 206(4)-7 and the Technology Program	`cfg.advisers-act.exception-register`
Security incidents and control failures generate a report that reaches the CCO on a defined interval without a person remembering to send it.	Monitoring platform, ticketing	Advisers Act Compliance and Cybersecurity: Rule 206(4)-7 and the Technology Program	`cfg.advisers-act.incident-reporting-to-cco`
Each record category's retention period is configured in the system that holds it, rather than relying on nobody deleting anything.	Archive, mail platform, document management	Books and Records: Electronic Retention Under Rule 17a-4 and Rule 204-2	`cfg.books-records.retention-period-set`
The archive either prevents alteration and deletion outright or maintains an audit trail that would reconstruct an altered or deleted record, and the firm knows which of the two it relies on.	Archive platform configuration	Books and Records: Electronic Retention Under Rule 17a-4 and Rule 204-2	`cfg.books-records.immutability-or-audit-trail`
Mail and messaging platforms journal to the archive at the server, so a user cannot prevent capture by deleting a message.	Mail platform, collaboration platform	Books and Records: Electronic Retention Under Rule 17a-4 and Rule 204-2	`cfg.books-records.journaling-enabled`
Unapproved messaging channels are blocked or unavailable on firm-managed devices, not merely discouraged in the employee handbook.	Mobile device management, endpoint policy	Books and Records: Electronic Retention Under Rule 17a-4 and Rule 204-2	`cfg.books-records.approved-channels-enforced`
A compliance user can search the archive by person and date range and export results without administrator help.	Archive access roles	Books and Records: Electronic Retention Under Rule 17a-4 and Rule 204-2	`cfg.books-records.search-and-export`
A legal hold overrides the retention schedule and suspends automated deletion for the accounts it covers.	Archive retention policy	Books and Records: Electronic Retention Under Rule 17a-4 and Rule 204-2	`cfg.books-records.deletion-suspension`
Communications subject to supervisory review arrive in a review queue with lexicon or risk-based flagging, and reviewer actions are recorded in the system rather than in a spreadsheet alongside it.	Surveillance / archive review module	FINRA Supervision and Cybersecurity: Rule 3110 and Broker-Dealer Technology Controls	`cfg.finra-supervision.review-queue`
Supervisory reviewers can see what they are required to review and cannot alter or delete the underlying records.	Archive and surveillance access roles	FINRA Supervision and Cybersecurity: Rule 3110 and Broker-Dealer Technology Controls	`cfg.finra-supervision.reviewer-permissions`
Devices used for firm business meet a defined posture — managed, encrypted, patched, screen-locked — regardless of whether they are in an office.	Endpoint management	FINRA Supervision and Cybersecurity: Rule 3110 and Broker-Dealer Technology Controls	`cfg.finra-supervision.remote-device-posture`
Every office and remote location reaches firm systems through the same controlled path, with no location-specific exception that bypasses it.	Network and remote access configuration	FINRA Supervision and Cybersecurity: Rule 3110 and Broker-Dealer Technology Controls	`cfg.finra-supervision.branch-network-standard`
Recovery time and recovery point objectives are configured in the backup and failover systems, not only asserted in the plan document.	Backup and disaster recovery configuration	FINRA Supervision and Cybersecurity: Rule 3110 and Broker-Dealer Technology Controls	`cfg.finra-supervision.bcp-recovery-targets`
Changes to a client's address, phone number, email, or bank instructions generate an alert and a notification to the client on a previously held contact method.	CRM, custodial platform, portfolio accounting	Regulation S-ID: Identity Theft Red Flags, at a High Level	`cfg.reg-s-id.profile-change-alerting`
Disbursement or transfer instructions received by email or portal message require verbal or out-of-band verification against a previously held contact record before execution.	Operations workflow, wire approval process	Regulation S-ID: Identity Theft Red Flags, at a High Level	`cfg.reg-s-id.disbursement-verification`
Client-facing portal and firm account logins from unexpected locations, new devices, or impossible-travel patterns generate an alert that a person sees.	Identity provider, client portal	Regulation S-ID: Identity Theft Red Flags, at a High Level	`cfg.reg-s-id.anomalous-login-alerting`
The identity verification performed at account opening, and any later re-verification, is recorded against the account rather than remembered by the person who did it.	Onboarding system, CRM	Regulation S-ID: Identity Theft Red Flags, at a High Level	`cfg.reg-s-id.identity-verification-record`
A triggered red flag creates a case record with the disposition, so the annual report can describe incidents rather than estimate them.	Ticketing or case management	Regulation S-ID: Identity Theft Red Flags, at a High Level	`cfg.reg-s-id.red-flag-case-record`
One vendor register is authoritative, and it records for each provider: the data it can reach, the access mechanism, the tier, the notification contact, the last review date, and the contract's notification status.	Vendor register	Vendor and Service-Provider Oversight for Regulated Financial Firms	`cfg.vendor-oversight.register-of-record`
Users cannot grant a third-party application access to firm data without an approval step; consent to unapproved applications is blocked by default.	Identity provider — third-party app consent settings	Vendor and Service-Provider Oversight for Regulated Financial Firms	`cfg.vendor-oversight.integration-approval`
Vendor and support accounts hold only the privileges the engagement requires, are individually attributable rather than shared, and are time-bounded where the platform allows.	Identity provider, line-of-business applications	Vendor and Service-Provider Oversight for Regulated Financial Firms	`cfg.vendor-oversight.least-privilege-vendor-access`
Every vendor, contractor, and support account authenticating into firm systems is subject to the same multi-factor requirement as staff.	Identity provider, remote access	Vendor and Service-Provider Oversight for Regulated Financial Firms	`cfg.vendor-oversight.vendor-access-mfa`
Vendor and support session activity is logged and retained, so a vendor-originated incident can be scoped from the firm's own records.	Remote access, privileged access management	Vendor and Service-Provider Oversight for Regulated Financial Firms	`cfg.vendor-oversight.vendor-activity-logged`
The address a vendor would send a breach notice to is a monitored group rather than an individual, and it is watched outside business hours.	Mail routing, on-call	Vendor and Service-Provider Oversight for Regulated Financial Firms	`cfg.vendor-oversight.notification-inbox-monitored`
Multi-factor authentication is enforced, not optional, for every identity that can reach firm systems or customer information — including vendors, contractors, and interactive service accounts.	Identity provider conditional access	Access Control and MFA for RIAs, Broker-Dealers, and Funds	`cfg.access-mfa.mfa-enforced-all-identities`
Administrative, remote, and finance-authorising access requires a phishing-resistant factor rather than a code a user can be talked into reading aloud.	Identity provider, privileged access	Access Control and MFA for RIAs, Broker-Dealers, and Funds	`cfg.access-mfa.phishing-resistant-privileged`
Legacy and basic authentication protocols that bypass multi-factor enforcement are blocked at the platform, since an unblocked legacy path makes the MFA policy advisory.	Mail platform, identity provider	Access Control and MFA for RIAs, Broker-Dealers, and Funds	`cfg.access-mfa.legacy-auth-blocked`
Administrative privilege is requested and time-bounded rather than permanently assigned, and day-to-day work happens under a non-privileged identity.	Identity provider, privileged access management	Access Control and MFA for RIAs, Broker-Dealers, and Funds	`cfg.access-mfa.no-standing-admin`
Every account maps to one accountable person or one registered owner; there are no shared logins whose activity cannot be attributed.	Identity provider, line-of-business applications	Access Control and MFA for RIAs, Broker-Dealers, and Funds	`cfg.access-mfa.unique-attributable-accounts`
Sessions expire, devices re-authenticate on a defined interval, and unmanaged devices do not hold a persistent session against client data.	Identity provider session policy	Access Control and MFA for RIAs, Broker-Dealers, and Funds	`cfg.access-mfa.session-controls`
Authentication successes, failures, MFA enrolment changes, and privilege grants are logged and retained long enough to scope an incident.	Identity provider audit log, log retention	Access Control and MFA for RIAs, Broker-Dealers, and Funds	`cfg.access-mfa.auth-events-logged`
Every identity exempt from a standard access control appears in an exception register with an owner, a reason, a compensating control, and an expiry date.	Exception register	Access Control and MFA for RIAs, Broker-Dealers, and Funds	`cfg.access-mfa.exception-register`
Identity, email, endpoint, and remote access logs are retained for a defined period long enough to scope a late-discovered incident, and are searchable across that entire period rather than only the recent part.	Log platform, identity provider, endpoint platform	Incident Response and Exam Evidence for Financial Firms	`cfg.incident-response.log-retention-window`
Security alerts route to a monitored queue with a defined response time and an out-of-hours path, never to a single person's mailbox.	Monitoring platform, on-call rotation	Incident Response and Exam Evidence for Financial Firms	`cfg.incident-response.alert-routing`
Each incident creates one case record that carries the timeline, decisions, approvals, and artifacts, so the after-the-fact narrative does not have to be reconstructed from email.	Ticketing or case management	Incident Response and Exam Evidence for Financial Firms	`cfg.incident-response.case-record`
An incident communication channel exists that does not depend on the firm's email or network, and the participants have already used it.	Alternate communication tooling	Incident Response and Exam Evidence for Financial Firms	`cfg.incident-response.out-of-band-comms`
Backups cannot be deleted or encrypted by a compromised administrative account, and at least one copy is isolated from the production identity system.	Backup platform	Incident Response and Exam Evidence for Financial Firms	`cfg.incident-response.immutable-backups`
Containment steps preserve evidence — images or snapshots taken before rebuilding — so scope can still be determined after the environment is clean.	Endpoint and server response runbooks	Incident Response and Exam Evidence for Financial Firms	`cfg.incident-response.evidence-preservation`
Deal and investor data rooms carry an expiry or an access review date, so a closed transaction does not leave standing access in place indefinitely.	Virtual data room, file sharing platform	Private Fund and PE Adviser Technology Notes	`cfg.private-funds.deal-room-expiry`
External participants — counsel, bankers, diligence providers, portfolio company staff — authenticate as guests with multi-factor authentication and attributable identities, not through a shared link or a shared login.	Identity provider guest access, data room	Private Fund and PE Adviser Technology Notes	`cfg.private-funds.external-participant-identity`
Deal folders are restricted by group membership and access is logged, so an information barrier is a permission rather than an instruction.	File storage permissions, audit logging	Private Fund and PE Adviser Technology Notes	`cfg.private-funds.information-barrier-enforced`
Portfolio companies operate in identity and email tenants separate from the adviser's, with no shared administrative credentials between them.	Identity architecture	Private Fund and PE Adviser Technology Notes	`cfg.private-funds.portfolio-tenant-separation`
Capital call and distribution instructions require out-of-band verification and dual authorisation, and the approval is recorded with the transaction.	Treasury workflow, banking platform	Private Fund and PE Adviser Technology Notes	`cfg.private-funds.wire-authorisation-controls`
Investor communications are captured into the archive on the same basis as other business communications, including messages sent from mobile devices.	Mail platform, archive	Private Fund and PE Adviser Technology Notes	`cfg.private-funds.investor-communication-capture`
Valuation and performance calculation support is stored where it cannot be silently altered, with version history retained.	Document management, archive	Private Fund and PE Adviser Technology Notes	`cfg.private-funds.valuation-support-immutability`

Frequently Asked Questions

What does a reasonable basis mean in practice?

It means the conclusion rests on something someone examined. A review that restates the policy has no basis; a review that cites the last access review's removals, a restore test's elapsed time, and a log retention search has one. The test to apply to each check below is whether you could hand over the named artifact today.

Do we have to complete every check?

No. Checks attached to rules your firm is not subject to do not apply, and you should record that determination rather than leaving the row blank. What is not defensible is a check that applies, was not performed, and was not identified as not performed.

Who should run this checklist?

Whoever signs the conclusion — usually the CCO — with the underlying artifacts produced by internal technology staff or an outside provider. The one arrangement to avoid is the provider assessing its own work with no independent visibility for the firm, because then the firm has an opinion rather than a basis.

How is this different from the scheduled actions page?

Scheduled actions is forward-looking: the work to put on a calendar. This page is backward-looking: the evidence that the work happened. Run the actions during the year; run this checklist when you need to conclude something about the year.

Companion rollup: all scheduled actions. Back to the Compliance Library hub.

Author: Rachel Lannon and Byron Foley
Reviewed by: Tim Quinn
Last updated: September 15, 2026

This is operational technology guidance for regulated firms, not legal advice. Confirm how each requirement applies to your firm with your compliance counsel.