DocsPrograms

Cybersecurity & security incidents

Updated 2026-10-07

Your information security program lives in the Cybersecurity group of the sidebar, which holds three screens. Cybersecurity is the landing page for the program. Security incidents is the register of incidents and the notices they trigger. Continuity (BCM) is the business continuity register, covered in Business continuity. The group belongs to the Cybersecurity job family, which arranges the sidebar for the information security officer and the continuity lead. See Roles & permissions and, for the buyer-facing summary, cybersecurity.

The Cybersecurity page

The Cybersecurity page brings the program together from records you already keep. Anyone who can read the control catalogue can open it. It reads the information security and continuity frameworks your institution has enrolled and keeps in scope. Those are the FFIEC IT booklets, GLBA including the Interagency Guidelines Establishing Information Security Standards, NCUA Chapter VII including Part 748, the FFIEC business continuity booklet, NIST CSF 2.0, the CRI Profile, NIST SP 800-53, the CIS Controls, ISO/IEC 27001, NYDFS Part 500 and PCI DSS.

  • Frameworks. This panel shows each enrolled framework with its coverage, its citations, its open gaps and its owner, and names the frameworks on the list you have not enrolled.
  • Board report. This panel tracks the annual report to the board described below.
  • Security incidents. This panel lists the open and contained incidents with the notices still due on each, earliest deadline first. This panel appears only for people who can read the incident register.
  • Open findings. This panel lists the open findings tagged to those frameworks.
  • Controls. This panel lists the controls crosswalked to those frameworks, with each control's test status of test overdue, test due soon, no test schedule or tested, and the date its next test is due. The panel heading counts the mapped controls and the overdue tests.

Continuity (BCM) at the top of the page takes you to the continuity register. A framework mapping is a crosswalk and never certification evidence.

The Interagency Guidelines, at section III.F, expect management to report to the board at least annually on the overall status of the information security program and the institution's compliance with the Guidelines. For a bank they are codified at 12 CFR 30 Appendix B and its counterparts, and for a credit union at 12 CFR 748 Appendix A. The Board report panel shows that obligation from the obligations calendar with its due date and a status of overdue, due soon or scheduled, and when it was last reported.

Generate report produces the report for the twelve months ending on the day you generate it, as a PDF, and is available to people who can edit controls. Its seven sections follow section III.F one to one. They cover overall status and compliance, the risk assessment, risk management and control decisions, service provider arrangements, and the results of testing, which include control tests, automated tests and continuity exercises. Then come security breaches or violations and management's responses, drawn from the incident register, and recommendations for changes in the program.

Sections 1 to 6 are computed from your registers, and every figure is sealed as a claim that resolves back to the records that produced it. Section 7 is your information security officer's own text. Start recommendations opens it as a collaborative draft, and generating the report seals the current version into the report. The report is filed as a board report, so it reaches the Board packs panel of the board portal alongside the other sealed board reports, and its claims can be re-verified later. See Board & governance. After you generate it, someone who can manage settings can choose Record as met to mark the annual obligation complete on that date. Examiner sessions do not see the board report.

Record incident on the Security incidents screen opens a new incident. You record a title, an optional description, a severity of critical, high, medium or low, the time it was detected, the affected systems, and optionally the service provider involved, chosen from your third-party register. You also tick the information involved, which can be sensitive customer information, other customer information, employee information, credentials, or confidential business information. Then you record how many customers or consumers were affected, if you know, and whether it occurred at an entity the FTC Safeguards Rule covers, such as a non-bank affiliate or a CUSO.

The register lists each incident with its severity, its detection time, the next notice due and its status of open, contained or closed, and you can filter it by status. Opening an incident shows its notification regimes, its evidence and its links to other records.

The most important act on an incident is Record determination. A named member of your team records when they determined it, whether it is a notification incident that must be reported, and the basis for that conclusion. Zovos never makes that determination, and until one is recorded no regulator deadline runs. A determination cannot predate detection. To change it you choose Record a new determination and give a reason for the change, and the earlier determination stays in the audit trail.

Each incident carries a row for every notification regime. The row says whether the regime applies and why, the citation it comes from, and its deadline or the rule that sets one.

  • Primary federal regulator. A bank notifies its primary federal regulator as soon as possible and no later than 36 hours after the determination. The citation follows your primary federal regulator, which is 12 CFR 53.3 for the OCC, 12 CFR 225.302 for the Federal Reserve and 12 CFR 304.23 for the FDIC.
  • NCUA. A credit union notifies NCUA as soon as possible and no later than 72 hours after the determination, under 12 CFR 748.1(c).
  • Customer notice. Under the response-program guidance, affected customers are notified as soon as possible when misuse of their sensitive information has occurred or is reasonably possible. The guidance sets no fixed hours, and whether misuse is reasonably possible is your judgment, so once sensitive customer information is involved you mark whether this notice applies.
  • Federal Trade Commission. An entity the Safeguards Rule covers notifies the FTC as soon as possible and no later than 30 days after discovery when customer information of 500 or more consumers is involved, under 16 CFR 314.4(j). The clock runs from the detection time you recorded.
  • Suspicious activity report. The row records only that the SAR question was considered, when, and by whom. The decision and any filing stay with your BSA officer, outside this record.
  • Cyber insurer and state breach-notification law. Your policy and each state's statute set their own terms, so you mark whether each applies, and the state-law row holds the states and their terms in your own words.

Record on a row captures the notice once it is sent. You record when it was sent, to whom, who sent it, the agency's reference, and the evidence item that proves it, which you attach under the incident's Evidence first. A regime that applies and has a deadline reads Notice due until its notice is recorded as sent.

Close incident requires the root cause and the lessons learned, and a closed incident can no longer be edited. Three follow-up actions connect an incident to the rest of the program.

  • Promote to finding. This opens a self-identified finding from the incident in the findings register. This needs permission to write findings.
  • Raise a task. This creates a task with an owner, linked to the incident. This also needs permission to write findings.
  • Book the loss. This links an existing loss event or creates a new one with its event type and gross loss amount, in the loss events register. This needs permission to write risk records.

See Findings & remediation and Risk management.

Zovos records the determination your team makes and the notices your team sends. It does not decide whether an incident is reportable, send any notice, or monitor your systems for incidents. The incident register has its own read and write permissions, separate from the continuity permissions, so you can staff your information security officer without handing over business continuity, or the reverse. Examiner sessions never see the incident register.