Bermuda BMA Cybersecurity Code of Conduct: what the annual attestation actually requires
Sienna VanceApril 29, 2026
Key takeaways
The BMA Cybersecurity Code of Conduct requires annual attestation signed by a senior officer confirming that the entity meets the Code's minimum cybersecurity standards. The attestation is not self-certification — it creates regulatory liability for the officer who signs it, and the BMA can request the underlying evidence at any time.
BMA CCC requires notification of material cybersecurity incidents to the BMA within 72 hours of discovery. The notification must include a description of the incident, systems affected, data potentially compromised, and containment actions taken. Entities that notify late or with incomplete content face regulatory scrutiny independent of the incident itself.
The Code requires entities to maintain contractual rights to audit material third-party service providers and to verify that those providers meet cybersecurity standards equivalent to those required of the entity itself. Standard cloud provider enterprise agreements typically lack these audit rights, creating a direct Code compliance gap for entities that have not negotiated bespoke terms.
Bermuda's insurance and reinsurance sector operates under BMA CCC alongside NYDFS Cybersecurity Regulation for US-facing entities, creating overlapping but non-identical obligations. The governance structures, incident reporting timelines, and third-party requirements differ between the two frameworks in ways that a single unified compliance program will miss.
In Vulnox gap assessments of Bermuda-regulated financial entities, the most common finding is not in governance documentation — Board policies and cybersecurity frameworks are generally present. The gap is in control effectiveness evidence: the documentation demonstrating that stated controls are operating as described, which BMA examiners request and most entities cannot immediately produce.
BMA CCC applies to banks, insurers, reinsurers, trust companies, and fund administrators licensed by the BMA. The Code's requirements are proportionate to entity size and complexity, but proportionality does not mean exemption — smaller entities are expected to meet minimum standards calibrated to their risk profile, not to be exempt from them.
TL;DR
The BMA Cybersecurity Code of Conduct creates real regulatory liability through its annual attestation mechanism — the senior officer who signs it is confirming control effectiveness, not policy existence. Most Bermuda financial entities have the governance documentation the Code requires. Fewer have the control effectiveness evidence that makes the attestation defensible if the BMA examines it. The gap between signing the attestation and being able to support it with evidence is where BMA compliance programs most commonly fail.
What happens when the BMA follows up on an attestation
A mid-sized Bermuda reinsurer completed its annual BMA CCC attestation on schedule. The Board had approved the cybersecurity report, the CISO had reviewed the compliance checklist, and the designated senior officer had signed. Six months later, following a cybersecurity incident at a peer firm, the BMA issued a sector-wide information request to several reinsurers asking for evidence supporting specific attestation items — specifically, evidence of third-party vendor cybersecurity assessments conducted during the prior 12 months, and documentation of penetration testing results against critical systems. The reinsurer had conducted a penetration test. The report existed. What it did not have was documented remediation tracking showing that findings from that test had been addressed before the attestation was signed. The third-party vendor assessments consisted of vendor-completed questionnaires, not independent verification.
The attestation had been signed in good faith. The control effectiveness evidence did not support what the attestation stated. The BMA's information request exposed the gap between the governance layer — policies, Board reports, attestation signatures — and the operational layer — what controls were actually doing and what evidence existed to demonstrate it. That gap is not unusual. It is the default state of BMA CCC compliance programs that are built around attestation deadlines rather than around the evidence standards that make attestations defensible.
What the BMA Cybersecurity Code of Conduct actually requires
The BMA Cybersecurity Code of Conduct, issued under the BMA's supervisory authority over licensed financial entities in Bermuda, establishes minimum cybersecurity standards across six domains: governance and accountability, cyber risk management, cybersecurity controls, third-party risk management, incident response and reporting, and the annual attestation. The Code is principles-based in its governance requirements — it describes expected outcomes rather than prescribing specific technical implementations — but it is specific on procedural obligations: the attestation requirement, the incident reporting timeline, and the third-party audit rights obligation are concrete requirements, not interpretive guidelines.
The annual attestation requirement is the compliance mechanism that creates the most regulatory exposure. A designated senior officer must attest annually that the entity has implemented the minimum cybersecurity standards set out in the Code. That attestation is a regulatory declaration. If the BMA examines the underlying controls and finds that the attestation was signed without supporting evidence, the compliance failure is not just in the control gap — it is in the attestation itself. Senior officer attestations that are not supportable by control effectiveness documentation create personal regulatory liability for the signatory.
The governance requirements are structured around Board-level ownership. The Board is expected to approve the cybersecurity strategy, receive regular reporting on cybersecurity posture and incident trends, and review the annual attestation before it is submitted. Board approval of a cybersecurity report that contains materially inaccurate statements about control effectiveness is itself a governance failure under the Code.
Example
The incident reporting requirement creates the most operationally demanding timeline. The Code requires notification to the BMA within 72 hours of discovering a material cybersecurity incident. The notification must contain specific content: a description of the nature of the incident, the systems and data affected, an assessment of the potential impact, and the containment measures implemented or planned. An entity that notifies within 72 hours with incomplete content has technically missed the requirement — the 72-hour window applies to a complete notification, not a placeholder. Entities that build IR plans around notifying 'something' within 72 hours and completing the report later are not compliant with the Code's notification content standard.
The third-party risk requirement is where the gap between contractual language and operational compliance most frequently appears. The Code requires entities to conduct due diligence on material service providers' cybersecurity controls and to maintain ongoing oversight of vendor cybersecurity posture. It requires contractual provisions giving the entity the right to audit vendors and requiring vendors to notify the entity promptly of cybersecurity incidents. Major cloud providers — AWS, Microsoft Azure, Google Cloud — offer enterprise agreements that include security documentation, SOC 2 reports, and ISO 27001 certifications. None of those standard agreements include audit rights clauses that satisfy the BMA CCC requirement. Entities using cloud infrastructure under standard enterprise terms without negotiating supplementary security addenda are carrying a direct Code compliance gap.
The compliance numbers that define BMA CCC exposure
72 hours
BMA CCC incident reporting window from discovery of a material cybersecurity incident. The notification must include incident description, affected systems and data, impact assessment, and containment actions. Incomplete notifications do not satisfy the requirement. Entities whose IR plans trigger BMA notification only after internal triage is complete — which often takes 24-48 hours — are compressing the remaining window for preparing a complete, content-compliant notification to a point where errors become likely.
Annual
Frequency of the BMA CCC attestation requirement. The attestation must be signed by a designated senior officer and submitted to the BMA confirming that the entity meets minimum cybersecurity standards. The BMA can request the underlying control effectiveness evidence at any point. Entities that treat the attestation as an annual checkbox rather than as a liability-creating declaration are underestimating the regulatory exposure they are accepting when the senior officer signs.
Six domains
Structure of the BMA CCC: governance and accountability, cyber risk management, cybersecurity controls, third-party risk management, incident response and reporting, and the attestation mechanism. Each domain has minimum standards that must be met before attestation. Gap assessments that evaluate governance and controls without separately assessing third-party risk management are systematically incomplete — third-party risk is where the most common and most documentable gaps exist in Bermuda financial entity compliance programs.
Class 3A through 4 insurers
BMA CCC applicability tier most commonly associated with full Code compliance requirements. Smaller entities face proportionate requirements, but 'proportionate' in BMA usage means calibrated control implementation — not reduced documentation or attestation obligations. A Class 3A insurer with $500 million in premiums written faces the same attestation mechanism and the same 72-hour incident reporting obligation as a Class 4 reinsurer, with controls calibrated to operational complexity.
What gap assessments find in Bermuda-regulated financial entities
Assessment base: Vulnox gap analysis engagements with BMA-regulated financial and insurance entities in Bermuda, 2023-2024
Penetration testing is conducted but remediation tracking against findings is absent at attestation time
BMA CCC requires entities to conduct regular penetration testing and vulnerability assessments as part of their cybersecurity controls obligation. In gap assessments of Bermuda-regulated insurers and reinsurers, penetration tests are generally conducted — often annually, sometimes more frequently for larger entities. The consistent gap is not in whether the test happened but in whether findings were remediated and whether that remediation was documented before the attestation was signed. Entities sign attestations confirming that cybersecurity controls meet minimum standards while carrying open penetration test findings that contradict that statement. The test report exists. The remediation evidence does not.
A signed attestation covering a period during which known penetration test findings remained unremediated creates a specific regulatory exposure. The BMA examiner who requests the penetration test report and the remediation tracking register will find a gap between the attestation statement and the documented control state. That gap is harder to explain than a delayed attestation or a remediation extension request would have been.
Third-party vendor assessments rely on questionnaires rather than independent verification
BMA CCC's third-party risk requirements explicitly contemplate active verification of vendor cybersecurity posture, not reliance on vendor-completed questionnaires. In assessed Bermuda entities, vendor risk management programs typically consist of annual questionnaires sent to material vendors, review of vendor-provided SOC 2 reports, and ISO 27001 certificate verification. Independent verification — accessing vendor environments, reviewing vendor scan data, or commissioning third-party audits of vendor controls — is absent in most programs. Vendor-completed questionnaires systematically overstate vendor security posture. SOC 2 reports cover the controls the auditor examined, not the controls the BMA would want verified.
An entity whose third-party risk management program consists of questionnaires and certification reviews cannot produce evidence of the active vendor oversight that BMA CCC contemplates. When the BMA requests documentation of vendor cybersecurity assessments, the entity produces questionnaire responses. That is not what the Code requires, and the distinction will be apparent to an examiner who understands the difference between vendor self-reporting and independent oversight.
Board cybersecurity reporting satisfies governance form without informing governance decisions
BMA CCC requires active Board engagement in cybersecurity governance, including regular reporting on cybersecurity posture, incident trends, and compliance status. In assessed entities, Board cybersecurity reports exist and are presented at the required frequency. The content of those reports is the gap. Reports that present traffic-light status indicators without the underlying metric data do not give Board members the information needed to make risk-informed decisions. Boards that approve cybersecurity strategies based on RAG status reports rather than on control effectiveness data are satisfying the form of the governance requirement without satisfying its substance. The BMA's governance assessment looks at whether Board reporting enables informed oversight — not whether reporting happened.
An entity whose Board has approved cybersecurity strategy and attestation based on status indicators rather than control effectiveness data has a governance gap that is visible in the Board minutes. If the BMA examines the Board reporting package and finds that the Board did not have the information needed to evaluate what it approved, the governance failure is documented in the entity's own records.
NYDFS cybersecurity certification experience does not transfer to BMA CCC attestation
Common belief
Bermuda reinsurers with US operations that have completed NYDFS cybersecurity certification already understand the attestation model and can apply that compliance infrastructure directly to BMA CCC.
What we found
In assessments of Bermuda reinsurers that had previously completed NYDFS compliance programs, the BMA CCC gaps were consistently in vendor contract terms and Board reporting quality. NYDFS compliance had produced control documentation and IR procedures that transferred well. It had not produced the vendor audit rights clauses BMA CCC requires or the control effectiveness reporting that BMA's governance expectations contemplate. The NYDFS compliance infrastructure was necessary but not sufficient for BMA CCC attestation.
NYDFS and BMA CCC both use senior officer attestation mechanisms and both address cybersecurity governance, incident reporting, and third-party risk. The surface similarity leads compliance teams to treat BMA CCC as an extension of NYDFS work rather than as an independent assessment. The operational requirements diverge in three specific ways that matter for evidence production. NYDFS has specific control requirements with defined implementation standards — multifactor authentication coverage percentages, penetration testing frequencies, CISO qualifications. BMA CCC is more principles-based in control requirements but more specific on the attestation accountability mechanism, which creates different evidence demands. NYDFS incident reporting uses a 72-hour window from determination that a cybersecurity event has occurred. BMA CCC uses a 72-hour window from discovery. That distinction matters for how IR triage procedures are designed. NYDFS third-party requirements focus on covered service providers meeting the regulation's standards. BMA CCC's third-party requirements focus on contractual audit rights and active verification — a different operational obligation that requires different vendor contract terms.
What Bermuda compliance teams say before the gap assessment, and what is actually happening
We completed our BMA CCC attestation last year and received no follow-up from the BMA. We must be in good shape.
Root cause:BMA examinations and information requests are not triggered by every attestation submission. The BMA reviews attestations and may request follow-up based on sector risk signals, incident notifications from peer firms, or examination cycles that do not necessarily align with attestation timing. The absence of BMA follow-up after an attestation does not confirm that the attestation was supportable — it confirms that the BMA did not request supporting documentation for that cycle. An attestation signed without underlying control effectiveness evidence is a regulatory exposure that persists until the BMA examines it, not one that expires when the year closes.
Our vendors are ISO 27001 certified and provide SOC 2 Type II reports. That satisfies our third-party risk obligations under BMA CCC.
Root cause:BMA CCC requires entities to maintain contractual rights to audit material service providers and to actively verify vendor cybersecurity posture. ISO 27001 certification and SOC 2 reports demonstrate that a vendor has a security program that satisfied an auditor's review at a point in time. They do not give the entity the audit rights that BMA CCC requires, and they do not constitute active verification by the entity of the specific controls the Code contemplates. The vendor documentation satisfies a due diligence step. It does not satisfy the contractual and oversight requirements.
Our Board receives a cybersecurity update every quarter. Governance is covered.
Root cause:BMA CCC's governance requirements address the quality of Board oversight, not only its frequency. A quarterly update that presents status indicators without control effectiveness data does not give the Board the information it needs to fulfill its oversight role under the Code. The BMA's governance assessment looks at whether the Board can demonstrate informed decision-making on cybersecurity risk — which requires that Board reporting contain actionable data, not summary ratings. Frequency of reporting satisfies the cadence requirement. Content of reporting determines whether the governance requirement is substantively met.
Where BMA CCC compliance programs go dark
Incident notification content completeness
BMA CCC requires notification content to include the nature of the incident, systems and data affected, impact assessment, and containment measures. IR plans that build around notifying the BMA within 72 hours often treat the timing as the compliance target and underspecify the content requirements. An entity that sends a preliminary notification within 72 hours with incomplete content — 'we are investigating a potential incident' without the required specifics — has not satisfied the notification requirement. The BMA expects a substantive notification, not a placeholder. IR playbooks need to include content checklists aligned to BMA CCC's notification content requirements, not just escalation timelines.
Subcontractor risk within vendor chains
BMA CCC's third-party risk requirements extend to the subcontractors that material vendors use to deliver services. An entity that has verified the cybersecurity posture of its primary cloud provider but has not assessed that provider's material subcontractors — data center operators, managed security service providers, network carriers — has addressed the first tier of vendor risk without addressing the Code's scope. Most vendor risk management programs in Bermuda entities stop at the primary vendor. The Code's obligation does not.
Cyber risk quantification for Board reporting
BMA CCC's governance requirements expect Board oversight to be informed by cyber risk assessment data. Risk assessments that produce qualitative ratings — high, medium, low — without quantitative exposure estimates do not give Board members the information needed to make risk-informed resource allocation decisions. The BMA's governance assessment asks whether the Board has the information to fulfill its oversight role. A Board that has approved a cybersecurity budget without a quantified risk exposure assessment has approved spending without understanding what it is buying down. That is a governance gap that is visible in the Board minutes and cybersecurity report.
Where BMA cybersecurity supervision is heading
The BMA will issue updated CCC guidance within 18 months that explicitly addresses cloud service provider risk, including specific contractual requirements for audit rights and minimum security addenda terms, following a pattern of incidents in the Bermuda market that traced to cloud configuration failures at entities that relied on standard provider agreements.
The BMA has been responsive to market developments in its supervisory guidance. Cloud adoption in the Bermuda insurance and reinsurance sector has accelerated significantly since the Code was last updated. The gap between BMA CCC third-party risk requirements and standard cloud provider contract terms is structural and well-documented in gap assessments. Updated guidance that specifies cloud security addenda requirements would resolve a compliance interpretation question that entities currently handle inconsistently and would give the BMA a clearer examination standard.
Confidence: mediumIf the BMA does not issue cloud-specific guidance or updated CCC provisions addressing cloud provider contract requirements by end of 2026, this prediction fails. Monitor BMA consultation papers and supervisory circulars.Within 24 months, the BMA will conduct coordinated examination reviews of BMA CCC attestations across a defined sector segment — likely Class 3B and Class 4 reinsurers — requesting control effectiveness documentation for selected attestation items, establishing examination-backed accountability for attestation accuracy as a market norm.
The attestation mechanism creates regulatory liability only if entities understand that the BMA will examine attestations. A sector-wide information request following a material incident or as part of a supervisory cycle would make that accountability concrete and visible. The BMA has used thematic examinations in other regulatory domains. The CCC attestation mechanism is designed to support exactly this kind of supervisory sampling. One visible examination cycle that results in findings against entities whose attestations were not supportable will reshape how compliance programs approach the attestation.
Confidence: mediumIf the BMA does not conduct a publicly documented thematic examination or sector-wide information request specifically referencing BMA CCC attestation support documentation by end of 2027, this prediction fails.
The attestation model works — but not the way most entities are using it
The BMA CCC attestation is a well-designed compliance mechanism. A senior officer declaration creates accountability that a checklist submission does not. The problem is that most Bermuda entities have built compliance programs that produce an attestation rather than programs that make the attestation accurate. The sequencing is backwards: policies are drafted, Board reports are prepared, and the attestation is signed — then, if there is time, someone checks whether the controls described in those documents are actually operating. The attestation should be the last step of a compliance verification cycle, not the deadline that drives the cycle. Entities that build their BMA CCC programs around what the attestation requires them to demonstrate — control effectiveness evidence for each Code domain — produce both better compliance and more defensible attestations than entities that build around the deadline.
Counterargument
The counterargument is that for smaller Bermuda entities — fund administrators, smaller trust companies — the resource investment required to produce control effectiveness evidence across all Code domains before each attestation is disproportionate. Proportionality provisions in the Code exist for this reason, and the BMA has signaled in supervisory communications that it calibrates examination intensity to entity size and complexity. That is a fair point for the smallest entities. It does not extend to Class 3B insurers and Class 4 reinsurers, which represent the bulk of Bermuda's premium volume and face examination scrutiny commensurate with their market significance. For those entities, proportionality is not a compliance shortcut — it is a calibration of control implementation standards, not an exemption from evidence requirements.
What to review before the next attestation cycle
Pull the last penetration test report and check whether every finding rated high or critical has a documented remediation record with a closure date. If any remain open, document the risk acceptance decision and the business reason before the attestation is signed. That is the single most common gap between what a Bermuda entity attests to and what it can demonstrate — and it is the first thing a BMA examiner will request when examining an attestation. The attestation says controls meet minimum standards. The penetration test record is the evidence that contradicts or confirms that statement. Make sure they align before the senior officer signs.
Further Reading
Gap Analysis
framework gap analysisDigital Footprint
digital footprint analysisAmericas data privacy and cybersecurity frameworks: the complete compliance map
Bermuda BMA Cybersecurity Code of Conduct compliance and what the annual attestation actually requiresNIST Vulnerability Assessment Definition
NIST's vulnerability assessment definitionThird-Party Risk Management
third-party risk managementNIST SP 800-30 Risk Assessment Guide
NIST risk assessment guide
Frequently Asked Questions
What does the BMA Cybersecurity Code of Conduct annual attestation require?
The BMA CCC requires a designated senior officer to attest annually that the entity meets minimum cybersecurity standards across all Code domains: governance, risk management, cybersecurity controls, third-party risk, and incident response. The attestation is a regulatory declaration — the BMA can request the underlying control effectiveness evidence at any time. Entities that sign attestations without supporting documentation for stated controls create personal regulatory liability for the signing officer.
What is the BMA CCC incident reporting timeline?
BMA CCC requires notification to the Bermuda Monetary Authority within 72 hours of discovering a material cybersecurity incident. The notification must include the nature of the incident, systems and data affected, impact assessment, and containment measures taken or planned. Incomplete notifications do not satisfy the requirement — the 72-hour window applies to a substantive notification, not a preliminary placeholder.
What third-party vendor requirements does BMA CCC impose?
BMA CCC requires entities to conduct due diligence on material service providers, maintain contractual rights to audit those providers, verify that vendors meet cybersecurity standards equivalent to those required of the entity, and require vendors to notify the entity promptly of cybersecurity incidents. Standard cloud provider enterprise agreements do not include audit rights clauses that satisfy this requirement. Entities using major cloud infrastructure under standard terms without negotiated security addenda are carrying a direct Code compliance gap.
How does BMA CCC differ from NYDFS Cybersecurity Regulation for Bermuda reinsurers?
NYDFS uses a 72-hour incident reporting window from determination that a cybersecurity event has occurred. BMA CCC uses 72 hours from discovery — a different trigger that requires IR procedures to be designed differently. NYDFS has specific technical control standards; BMA CCC is more principles-based on controls but more specific on attestation accountability. BMA CCC's third-party requirements focus on contractual audit rights and active verification; NYDFS focuses on covered service providers meeting defined standards. NYDFS compliance infrastructure transfers partially but not completely to BMA CCC.
What evidence does the BMA request when examining CCC attestation compliance?
BMA examiners request control effectiveness evidence rather than policy documentation. Common requests include: penetration test reports with remediation tracking showing findings were addressed before attestation, documentation of third-party vendor assessments beyond questionnaire responses, Board reporting packages showing the content basis for Board cybersecurity approvals, incident response records demonstrating timely and complete BMA notification, and vendor contract terms showing audit rights provisions. Entities that can produce policy documents but not operational evidence face examination findings regardless of attestation status.
Does BMA CCC apply differently to insurers versus reinsurers versus trust companies?
BMA CCC applies to all BMA-licensed financial entities including banks, insurers, reinsurers, trust companies, and fund administrators. Requirements are proportionate to entity size and operational complexity — Class 3A and Class 4 insurers and reinsurers face full Code requirements calibrated to their premium volumes and operational scale. Smaller entities face proportionate control implementation standards but the same attestation mechanism and the same 72-hour incident reporting obligation. Proportionality calibrates control implementation; it does not reduce documentation or attestation requirements.
What is the most common BMA CCC compliance gap in Bermuda financial entities?
Based on Vulnox gap assessments, the most common gap is not in governance documentation but in control effectiveness evidence — specifically, penetration test findings that remain untracked for remediation at attestation time, third-party vendor risk programs that rely on questionnaires rather than independent verification, and Board reporting that presents status indicators without the underlying control effectiveness data the BMA's governance assessment expects. Governance documentation is generally present. The evidence that makes it defensible is not.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.