Technology errors and omissions
Everything BestInsurance Research holds on technology errors and omissions: 40 cited checks, 0 answered questions, 1 worked examples and 5 source records carrying 51 recorded claims. Free to read, no account, nothing to fill in.
40 checks that bear on this line
These are the deterministic checks the worksheets run. Each one cites the source it rests on, so a check is readable as a published rule whether or not you ever open the worksheet. Nothing is submitted and no field you type leaves your browser.
Cyber Control Readiness
No published control baseline is recorded, so there is nothing to map your answers onto.
Two current public baselines cover everything this module asks about: NIST Cybersecurity Framework (CSF) 2.0, published 2024-02-26, which organizes outcomes under GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, and RECOVER, and CISA Cross-Sector Cybersecurity Performance Goals Version 2.0, dated December 2025, which is aligned to those same CSF 2.0 functions and which the CISA program page describes as voluntary goals that strive to help small- and medium-sized organizations kickstart their cybersecurity efforts by prioritizing investment in a limited number of essential actions. Mapping to a named, dated edition means an answer you give today can be checked against a fixed public text later.
Multi-factor authentication is recorded as not in place on any account.
CISA CPG 3.F states that organizations require MFA to access assets using the strongest available method, and that all IT accounts leverage MFA with priority given to privileged administrative accounts. NIST CSF 2.0 carries the same outcome as PR.AA-03, users, services, and hardware are authenticated.
Multi-factor authentication is recorded as partial, and no answer here says which accounts are outside it.
A partial answer will be read differently by every reader unless the uncovered set is named. CPG 3.F asks that all IT accounts use MFA and that privileged administrative accounts for key systems be prioritized, so the question that matters is whether the uncovered accounts are administrative or remotely reachable, not how many there are.
Multi-factor authentication is in place but no dated written evidence of it is held.
This is a different open item from not having the control. Cyber underwriting has moved toward asking for control evidence rather than accepting a yes on its own, and CSF 2.0 GV.PO-01 treats policy as something established, communicated, and enforced, which implies it exists in writing. An enforced control with no artifact is hard to confirm and hard to re-confirm at the next renewal.
No offline or immutable backup copy is recorded.
CISA CPG 3.O directs organizations to securely store backups offsite and offline, and notes that adversaries delete data and disable recovery services to prevent system recovery. CSF 2.0 PR.DS-11 states that backups of data are created, protected, maintained, and tested. A backup that your own administrator credentials can reach is reachable by anyone who takes those credentials.
Offline or immutable backups are in place but no written backup inventory and retention schedule is held.
CPG 3.O asks organizations to develop a list of all maintained backups, including installation media, license keys, configuration information, and the retention period for the information. Without that list, nobody can say during an incident what exists, how far back it goes, or what is needed to stand a system up again.
No restore has ever been tested.
CPG 3.O directs that backups and recovery be tested on a recurring basis, no less than once per year, and that the integrity of backups be validated before restoration is started. CSF 2.0 adds RC.RP-03, the integrity of backups and other restoration assets is verified before using them for restoration.
Backups are recorded as in place while the restore test is recorded as never performed.
These two answers describe two different things, and taken together they say the recovery path is unproven. CSF 2.0 PR.DS-11 makes testing part of the outcome itself, backups of data are created, protected, maintained, and tested, and CPG 3.O pairs storing backups offline with testing backups and recovery at least annually.
Restores are tested but no dated written result for the most recent test is held.
CPG 3.O expects testing on a recurring basis with integrity validated before restoration, and CSF 2.0 ID.IM-02 treats improvements identified from tests and exercises as an outcome in its own right. A test that produced no record cannot show a date, a scope, or what was fixed afterwards.
The last recorded restore test is more than twelve months old.
CPG 3.O sets the cadence explicitly: test backups and recovery on a recurring basis, no less than once per year. The date you entered is more than twelve months old, so the stated annual cadence has lapsed.
No endpoint detection is recorded on laptops, desktops, or servers.
CPG 4.A directs organizations to implement both signature-based mechanisms and non-signature-based mechanisms focused on behavior, heuristics, or anomalies to detect and eradicate malicious code at system endpoints, organization-wide. CSF 2.0 DE.CM-01 covers the monitoring side, networks and network services are monitored to find potentially adverse events.
Endpoint detection is in place but no dated coverage report is held.
Coverage is the part of this control that drifts, because new devices arrive and old ones leave. CPG 4.A scopes malicious code detection organization-wide and asks that the software be updated, active, and configured to scan automatically, which is a claim about every device rather than about the tool. A dated coverage report is the artifact that supports the claim.
No defined patch cadence is recorded.
CPG 2.B directs organizations to implement a vulnerability management program to patch and mitigate misconfigured software in a timely manner across all organizational assets, including those that face the internet, and notes that adversaries frequently target unpatched and misconfigured systems. CSF 2.0 PR.PS-02 states that software is maintained, replaced, and removed commensurate with risk.
Patch cadence is recorded as partial, which leaves open which assets are outside the schedule and why.
CPG 2.B scopes patching to all organizational assets, to include those that face the internet, and in its operational technology note asks that where patching is not possible compensating controls such as segmentation or monitoring be applied and recorded. A partial answer becomes answerable once the exceptions are named and the reason for each is written down.
A patch cadence is followed but there is no written patching standard and no record of what was patched when.
CPG 2.B asks for a vulnerability management program and for progress to be monitored through artifacts such as a plan of action and milestones, a risk register, or risk detail reports, with responsibilities assigned and procedures followed. Those are all written things, so a cadence that leaves no record cannot demonstrate timeliness after the fact. CSF 2.0 PR.PS-02 is the underlying outcome.
The number of individuals whose personal information you hold is recorded as unknown.
CPG 2.A asks organizations to maintain a regularly updated inventory of all organizational assets, expressly including data, and CPG 3.K asks you to identify critical electronic file types and data to protect while in transit and at rest, which may include personally identifiable information. CSF 2.0 places asset management in the IDENTIFY function. An unknown here also means notification exposure cannot be scoped later, since deadlines run from discovery rather than from when you finish counting.
Payment card transactions are accepted and awareness training is not recorded as in place for all users.
CPG 3.J names the specialized roles that warrant additional, role-based cybersecurity training, and finance personnel, senior leadership, and anyone with access to business-critical data are on that list alongside system administrators. Where money moves, the roles that move it are the ones the training is aimed at, and CPG 3.K asks separately that critical electronic file types and data be identified and protected while in transit and at rest.
Neither email filtering nor sender authentication is recorded as configured.
CPG 3.L states that on all corporate email infrastructure STARTTLS is enabled, SPF and DKIM are enabled, and DMARC is enabled and set to reject, in order to reduce risk from spoofing, phishing, and interception. CSF 2.0 PR.DS-01 and PR.DS-02 cover protecting data at rest and in transit.
Email filtering and sender authentication are in place but no dated record of the published configuration is held.
CPG 3.L is unusual among these controls because it is externally checkable, and it names a specific end state including DMARC set to reject. Recording what is published, and on what date, keeps a later answer honest if someone changes the policy value in the meantime.
Administrator rights are never re-reviewed.
CPG 3.G states that user accounts do not have administrator privileges, that administrators maintain separate user accounts for activities unrelated to their admin role such as business email and web browsing, and that privileges are re-evaluated on a recurring basis to validate continued need for a given set of permissions. CPG 3.H, a separate goal, asks that all user accounts, system roles, and processes operate with the minimum privileges necessary and that quarterly reviews of access permissions and role assignments be performed. CPG 3.D adds that user access should be reviewed and accounts disabled when inactive for a specified period, for example thirty days. CSF 2.0 PR.AA-05 requires access permissions to be defined in policy, managed, enforced, and reviewed with least privilege in mind.
Privileged access is reviewed but no dated review record or written offboarding checklist is held.
CPG 3.D asks for a defined and enforced administrative process to offboard staff, contractors, and vendors, including return of tokens or badges and revocation of all access. A review that leaves no record cannot show when it last happened or what changed, which is exactly what a later reviewer asks.
No incident response plan is recorded.
CPG 1.C directs organizations to develop, maintain, update, and regularly exercise incident response plans for common and organization-specific threat scenarios. CPG 4.B assumes the plan already exists, because it says that if an adverse event is suspected you follow the protocol outlined in the incident response plan to escalate. CSF 2.0 RS.MA-01 states that the incident response plan is executed in coordination with relevant third parties once an incident is declared.
An incident response plan exists in practice but is not written down.
This is the sharpest case of the difference between having a control and being able to evidence it. CPG 1.C asks that IR plans be developed, maintained, updated, and drilled, which are all acts performed on a document, and CSF 2.0 RS.MA-01 speaks of the plan being executed in coordination with third parties, which assumes third parties can be handed something. An unwritten plan also cannot be found during the outage that triggers it.
The incident response plan was last exercised more than twelve months ago.
CPG 1.C sets the cadence explicitly: IR plans should be reviewed and drilled, at a minimum, on an annual basis, and asks that drills be realistic and include all relevant stakeholders. The date you entered is more than twelve months old, so that stated cadence has lapsed. CSF 2.0 ID.IM-02 is the outcome the drill is for, improvements identified from security tests and exercises.
No security awareness training is recorded for people with accounts.
CPG 3.J directs that new employees receive initial cybersecurity training prior to accessing computer systems and that at least annual training be provided for all organizational users, covering recognizing social engineering attempts, reporting suspicious activity, and basic cyber hygiene. Its scope reaches employees, contractors, partners, suppliers, and other users of non-public resources. CSF 2.0 PR.AT-01 is the matching outcome.
Security awareness training happens but no dated completion record is held.
CPG 3.J is a coverage claim about all organizational users, not about whether a course exists, so the only thing that supports it is a record of who completed it and when. Underwriting review of cyber controls has moved toward asking for that kind of artifact rather than a yes.
The most recent training round closed more than twelve months ago.
CPG 3.J sets at least annual cybersecurity training for all organizational users. The date you entered is more than twelve months old, so the annual cadence has lapsed even though a programme exists.
The written evidence for these controls has not been assembled in one place.
Every control in this module resolves to an artifact somebody can read: a policy, a configuration export, a coverage report, a dated test result, a completion record, a backup inventory. Cyber underwriting increasingly turns on that evidence rather than on the answer alone, and assembling it once means the same pack serves renewal, a contract request, and an internal review.
A submission date is recorded while the control evidence is recorded as not assembled.
You have set yourself a date and have not yet gathered the artifacts the control answers rest on. The artifacts CPG 2.0 implies for these goals, including the backup inventory under 3.O, the drilled IR plan under 1.C, and the training records under 3.J, all take days to produce rather than minutes.
Nobody has been identified who can confirm the control answers in writing.
Applications are signed, and the control answers above are the part someone will be held to. CPG 1.A places cybersecurity roles, responsibilities, and authorities in writing as a governance outcome, asking that all roles and responsibilities involving cybersecurity be documented in an organization's cybersecurity policy, and CSF 2.0 GV.PO-01 treats policy as established, communicated, and enforced rather than assumed.
An outside provider runs IT and the security and notification terms of that agreement have not been read.
CPG 2.0 added net-new goals addressing managed service providers, least privilege, and incident communication procedures, and CPG 1.D covers notifying a customer of security incidents and vulnerabilities within a risk-informed time frame. Several answers above describe work the provider performs, so the agreement decides who must tell you, how fast, and what evidence you can obtain.
A hosted system holds customer or client records and its security and notification terms have not been read.
CPG 1.D concerns notifying a customer of security incidents and vulnerabilities within a risk-informed time frame, which is the same obligation running toward you from whoever holds your data. If a notification clock starts on discovery, the practical question is when the holder of the data tells you, because that is when your own clock can start.
A contract requires cyber or privacy liability coverage and no cyber coverage is recorded.
You have recorded a contractual requirement to carry this coverage and recorded none in force, which is a mismatch between an obligation you have accepted and what your programme shows. CSF 2.0 places supply chain and third-party commitments inside the GOVERN function as category GV.SC, Cybersecurity Supply Chain Risk Management, so this belongs with your governance records rather than being treated as a purchasing detail; the controls recorded above are a separate matter from the coverage question and neither substitutes for the other.
The recorded cyber limit is lower than the limit the strictest contract requires.
This is arithmetic on the two numbers you entered: the limit recorded on your coverage is less than the limit the contract demands. A shortfall against a contractual figure is a contract compliance question first, and it sits inside the same third-party governance work that CSF 2.0 collects under GV.SC, Cybersecurity Supply Chain Risk Management; matching numbers still does not mean two policies respond to the same thing.
A contract requires cyber coverage and the limit it demands is not recorded.
You recorded a contractual requirement to carry this coverage without recording the limit the clause names. Until that figure is written down there is nothing to compare a policy against, so the requirement cannot be checked at all. CSF 2.0 places third-party commitments inside the GOVERN function as category GV.SC, Cybersecurity Supply Chain Risk Management, which is where an obligation of this kind belongs on the record.
The limit a contract requires is recorded, and the limit actually carried is not.
You recorded what the clause demands but not what your own coverage carries, so the comparison this module would otherwise run cannot be run. The figure is on your declarations page rather than a matter of recollection. CSF 2.0 collects third-party commitments under GV.SC, Cybersecurity Supply Chain Risk Management.
Protected health information is handled, an incident is recorded as discovered more than sixty calendar days ago, and notification is recorded as not sent.
45 CFR 164.404(b) provides that a covered entity shall provide the required notification without unreasonable delay and in no case later than sixty calendar days after discovery of a breach. The discovery date you entered is more than sixty calendar days ago, so on the dates recorded that outer limit has already passed. Whether the event is a breach requiring notification at all is a legal determination, not something this module can decide.
Protected health information is handled, an incident was discovered within the last sixty calendar days, and notification is recorded as not sent.
45 CFR 164.404(b) requires notification without unreasonable delay and in no case later than sixty calendar days after discovery. The discovery date you entered is within the last sixty calendar days, so the outer limit has not yet passed; note that the without unreasonable delay wording means the sixty days is a ceiling and not a permitted waiting period.
The sector recorded is healthcare, and CISA publishes Healthcare Sector-Specific Goals beyond the cross-sector set.
CISA lists Sector-Specific Goals as available now for the Healthcare sector, described as voluntary practices that go beyond the Cross-Sector CPGs. Those goals are a published text you can map to by name, in the same way as the cross-sector goals in CPG 2.0, Version 2.0, December 2025.
A prior cyber incident is recorded while no written incident response plan is recorded.
The business has already been through the event the plan exists for, and the plan is still recorded as absent. CPG 1.C treats plan development, maintenance, and drilling as the mechanism for identifying improvements, and CSF 2.0 ID.IM-02 makes improvements identified from tests and exercises an explicit outcome.
Examples touching this line
Lines that share a worksheet with this one
A worksheet that covers this line also covers these, which usually means the same decision touches all of them.
Source ledger
5 sources. Every citation number above resolves to a record below. Nothing here sits behind an account.
- [1]The NIST Cybersecurity Framework (CSF) 2.0 (NIST CSWP 29)(opens the original record on National Institute of Standards and Technology, U.S. Department of Commerce)National Institute of Standards and Technology, U.S. Department of CommerceSecondaryPrimaryJurisdiction USPublished February 26, 2024Effective February 26, 2024Last checked August 31, 2026Updates: major-revisionID
nist-csf-2-0What this source supports (15)
- The current edition is CSF 2.0, published February 26, 2024, available free of charge at https://doi.org/10.6028/NIST.CSWP.29.
- CSF 2.0 organizes outcomes under six Functions: GOVERN (GV), IDENTIFY (ID), PROTECT (PR), DETECT (DE), RESPOND (RS), RECOVER (RC).
- PR.AA-03: Users, services, and hardware are authenticated.
- PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties.
- PR.AT-01: Personnel are provided with awareness and training so that they possess the knowledge and skills to perform general tasks with cybersecurity risks in mind.
- PR.DS-11: Backups of data are created, protected, maintained, and tested.
- PR.PS-02: Software is maintained, replaced, and removed commensurate with risk.
- DE.CM-01: Networks and network services are monitored to find potentially adverse events.
- RS.MA-01: The incident response plan is executed in coordination with relevant third parties once an incident is declared.
- RC.RP-03: The integrity of backups and other restoration assets is verified before using them for restoration.
- GV.PO-01: Policy for managing cybersecurity risks is established based on organizational context, cybersecurity strategy, and priorities, and is communicated and enforced.
- ID.IM-02: Improvements are identified from security tests and exercises, including those done in coordination with suppliers and relevant third parties.
- The CSF does not prescribe how outcomes should be achieved; it offers a taxonomy of high-level cybersecurity outcomes usable by any organization regardless of size, sector, or maturity.
- PR.DS-01: The confidentiality, integrity, and availability of data-at-rest are protected. PR.DS-02: The confidentiality, integrity, and availability of data-in-transit are protected.
- Cybersecurity Supply Chain Risk Management (GV.SC) is a category within the GOVERN function, covering cyber supply chain risk management processes identified, established, managed, monitored, and improved by organizational stakeholders.
Active - [2]Cross-Sector Cybersecurity Performance Goals, Version 2.0(opens the original record on Cybersecurity and Infrastructure Security Agency, U.S. Department of Homeland Security)Cybersecurity and Infrastructure Security Agency, U.S. Department of Homeland SecuritySecondaryPrimaryJurisdiction USPublished December 1, 2025Effective December 1, 2025Last checked August 31, 2026Updates: major-revisionID
cisa-cpg-2-0What this source supports (23)
- Cover page reads Cross-Sector Cybersecurity Performance Goals, Version 2.0, December 2025, Cybersecurity and Infrastructure Security Agency; marked TLP:CLEAR.
- Contents are organized as 1. GOVERN, 2. IDENTIFY, 3. PROTECT, 4. DETECT, 5. RESPOND, 6. RECOVER, aligning to NIST Cybersecurity Framework version 2.0.
- Goal 1.C MAINTAIN INCIDENT RESPONSE PLANS: organizations develop, maintain, update, and regularly exercise IR plans; IR plans should be reviewed and drilled, at a minimum, on an annual basis.
- Goal 1.D SUPPLY CHAIN INCIDENT REPORTING AND VULNERABILITY DISCLOSURE addresses notifying a customer of security incidents and vulnerabilities within a risk-informed time frame.
- Goal 2.C MITIGATE KNOWN VULNERABILITIES: implement a vulnerability management program to patch and mitigate misconfigured software in a timely manner, covering all organizational assets including those that face the internet.
- Goal 3.D REVOKE CREDENTIALS FOR DEPARTING STAFF: a defined and enforced administrative process to offboard staff including revocation of all access; review user access and disable accounts when inactive for a specified period, for example 30 days.
- Goal 3.F IMPLEMENT MULTIFACTOR AUTHENTICATION (MFA): organizations require MFA to access assets using the strongest available method; options sorted high to low are phishing-resistant MFA, then mobile app-based soft tokens, then SMS or voice only when no other options are possible; all IT accounts leverage MFA, prioritizing privileged administrative accounts.
- Goal 3.H IMPLEMENT THE PRINCIPLES OF LEAST PRIVILEGE: user accounts do not have administrator privileges, administrators maintain separate user accounts for non-admin activity, and privileges are re-evaluated on a recurring basis to validate continued need.
- Goal 3.J IMPLEMENT CYBERSECURITY TRAINING: new employees receive initial cybersecurity training prior to accessing computer systems, and at least annual cybersecurity training is provided for all organizational users covering recognizing social engineering, reporting suspicious activity, and basic cyber hygiene.
- Goal 3.M ENABLE EMAIL SECURITY: on all corporate email infrastructure STARTTLS is enabled, SPF and DKIM are enabled, and DMARC is enabled and set to reject.
- Goal 3.O MAINTAIN SYSTEM BACKUPS AND RESTORATION ABILITY: develop a list of all maintained backups including installation media, license keys, configuration information, and retention period; securely store backups offsite and offline; test backups and recovery on a recurring basis, no less than once per year; validate the integrity of backups before initiating restoration.
- Goal 4.A ESTABLISH MALICIOUS CODE DETECTION: implement signature-based and non-signature-based mechanisms to detect and eradicate malicious code at system endpoints, organization-wide.
- Goal 4.B IDENTIFY ADVERSE EVENTS: define clear criteria and processes for adverse events, and if an adverse event is suspected follow the protocol outlined in the incident response plan to escalate.
- The CPGs are voluntary and strive to help small- and medium-sized organizations kickstart cybersecurity efforts by prioritizing a limited number of essential actions.
- Goal 1.A ESTABLISH CYBERSECURITY RESPONSIBILITIES: roles, responsibilities, and authorities related to the organization's cybersecurity program are established, communicated, enforced, and aligned within the organization and external partners, and all roles and responsibilities involving cybersecurity should be documented in an organization's cybersecurity policy; scope reaches C-suite personnel, critical section leadership, physical and cybersecurity personnel, third-party contractors, vendors, and suppliers; NIST CSF 2.0 reference GV.RR-02.
- Goal 1.B MANAGE CYBERSECURITY OVERSIGHT is a separate goal: policies for managing the cybersecurity program are reviewed at least annually, updated when changes are applied, communicated, and enforced; NIST CSF 2.0 reference GV.OV-03.
- Goal 2.A MANAGE ORGANIZATIONAL ASSETS: maintain a regularly updated inventory of all organizational assets, meaning data, hardware, software, systems, facilities, and personnel, with IT and OT assets determined to be critical for business or operational functions updated on a more frequent basis.
- Goal 3.K UTILIZE STRONG ENCRYPTION: use encryption, digital signatures, and cryptographic hashes to protect the confidentiality and integrity of network communications, and identify critical electronic file types and data to protect while in transit and at rest, which may include personally identifiable information and sensitive, proprietary or trade secret information.
- Goal 2.B MITIGATE KNOWN VULNERABILITIES: implement a vulnerability management program to patch and mitigate misconfigured software in a timely manner, with a scope of all organizational assets, to include those that face the internet; monitor risk response progress through tools such as plan of action and milestones, risk registers, and risk detail reports; assign responsibilities and ensure procedures are followed. Goal 2.C is a different goal, OBTAIN INDEPENDENT VALIDATION OF CYBERSECURITY CONTROLS.
- Goal 3.G ADMINISTRATORS MAINTAIN SEPARATE USER AND PRIVILEGED ACCOUNTS: user accounts do not have administrator privileges, administrators maintain separate user accounts for activities unrelated to their admin role, such as business email and web browsing, and privileges are re-evaluated on a recurring basis to validate continued need for a given set of permissions.
- Goal 3.H IMPLEMENT THE PRINCIPLES OF LEAST PRIVILEGE: all user accounts, system roles, and processes operate with the minimum privileges necessary to perform their tasks, and quarterly reviews of access permissions and role assignments are performed to verify compliance with established policies.
- Goal 3.L ENABLE EMAIL SECURITY: on all corporate email infrastructure (1) STARTTLS is enabled, (2) Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) are enabled, and (3) Domain-based Message Authentication, Reporting, and Conformance (DMARC) is enabled and set to reject; the stated outcome is reduced risk from spoofing, phishing, and interception. Goal 3.M is a different goal, DISABLE AUTORUN AND MACROS BY DEFAULT.
- On small organizations the PDF says only that each organization faces unique cybersecurity challenges and that small- and medium-sized organizations may have limited budgets, staffing, and expertise; one of the stated criteria for a goal is that it be reasonably straightforward and not cost-prohibitive for small- and medium-sized entities to successfully implement. The voluntary and kickstart framing quoted in this module comes from the CISA program page, not from this PDF.
Active - [3]Cross-Sector Cybersecurity Performance Goals (program page)(opens the original record on Cybersecurity and Infrastructure Security Agency, U.S. Department of Homeland Security)Cybersecurity and Infrastructure Security Agency, U.S. Department of Homeland SecuritySecondaryPrimaryJurisdiction USPublished December 1, 2025Effective December 1, 2025Last checked August 31, 2026Updates: as-neededID
cisa-cpg-program-pageWhat this source supports (7)
- CISA's Cross-Sector Cybersecurity Performance Goals 2.0 are a subset of cybersecurity practices aimed at meaningfully reducing risks to critical infrastructure operations and the American people.
- Cross-Sector CPGs 2.0 have been updated to align to the NIST Cybersecurity Framework (CSF) 2.0 functions and build upon the foundation established in version 1.0.1, with the addition of the GOVERN function.
- Net-new goals address managed service providers (MSPs), the principle of least privileges, and incident communication procedures.
- The CPGs are intended as a baseline set of practices broadly applicable across critical infrastructure and a benchmark for operators to measure and improve.
- Sector-Specific Goals are available now for the Chemical, Energy (Distribution and Distributed Energy Resources), Healthcare, and Information Technology sectors, with Financial Services SSGs listed as coming.
- A new CSET assessment module for CPG 2.0 and an updated CPG 2.0 Checklist are noted as becoming available in Q1 2026.
- These voluntary Cross-Sector CPGs strive to help small- and medium-sized organizations kickstart their cybersecurity efforts by prioritizing investment in a limited number of essential actions with high-impact security outcomes.
Active - [4]Cyber COPE (R) Transforming Cyber Underwriting (by Patrick Thielen)(opens the original record on Chubb)ChubbCarrier officialSecondaryJurisdiction USLast checked August 31, 2026Updates: Standalone whitepaper; no published revision schedule.ID
chubb-cyber-cope-whitepaperWhat this source supports (4)
- The paper defines COPE as Construction, Occupancy, Protection, and Exposures, and calls it a straightforward and effective method of examining diverse measurements to help underwriters make better decisions about property risk.
- The paper refers to COPE as a time-tested property underwriting model.
- The paper opens with four sample questions it says insurance companies ask so they can properly and thoroughly underwrite risks presented for coverage: how tall is your office building, how close is the nearest fire hydrant, does the building have an alarm system, and are you in a flood zone.
- The paper states that in the 1700s the risk of fire made it difficult for many commercial property owners to secure the insurance coverage they needed, and that over time the industry adopted the COPE concept.
Fetched today. WebFetch returned PDF binary, so the text was extracted locally with pdftotext -layout and read directly. The title page reads Cyber COPE (registered mark) Transforming Cyber Underwriting, with no colon, and credits Patrick Thielen; the registered-trademark symbol is transliterated as (R) here to keep the record ASCII. No publication date appears in the extracted text, so publishedDate is left unknown. This is a cyber underwriting paper that describes the property COPE model it is adapting; it is cited only for its description of COPE, not as a commercial property underwriting guide. It says nothing about whether carriers must use COPE or about how application forms were designed.
Active - [5]45 CFR 164.404 - Notification to individuals (HIPAA Breach Notification Rule)(opens the original record on Cornell Legal Information Institute, reproducing the Code of Federal Regulations)Cornell Legal Information Institute, reproducing the Code of Federal RegulationsSecondarySecondaryJurisdiction USThird-party reproductionPublished January 25, 2013Effective March 26, 2013Last checked August 31, 2026Updates: on-amendmentID
cfr-45-164-404-liiWhat this source supports (2)
- Paragraph (b), Implementation specification: Timeliness of notification, provides that a covered entity shall provide the notification required by paragraph (a) without unreasonable delay and in no case later than 60 calendar days after discovery of a breach.
- The 60 calendar day period runs from discovery of the breach, and is an outer limit rather than a safe harbor, because notification must also be without unreasonable delay.
ActiveReproduction