Data Security During Insurance Data Migration 2026: The Regulatory Controls Playbook for P&C Carriers

Why data security during insurance data migration matters in 2026

The CIO I sat with at a US P&C carrier last fall - $1.6B GWP, three states, mostly personal lines - had just been through a state DOI examination. The examiner asked one question that, in my experience, separates carriers that have done migration security right from those that have not: “Show me the per-record audit trail for every PII record migrated in the last 24 months.” The CIO could produce the audit trail for the in-force book. They could not produce it for the 240,000 cancelled policies migrated alongside. The DOI examiner wrote a finding. The remediation took 7 months and cost more than the original migration contingency reserve.

That finding is the shape of the problem in 2026. Data security during insurance data migration is no longer a checkbox at the end of the architecture review. It is the artefact a state DOI examiner asks for in the next examination cycle, and the artefact that determines whether your migration is “complete and compliant” or “complete with findings.” In my experience leading or advising on more than 15 insurance migration programs since 2010, this is the dimension that has moved most aggressively from “important” to “regulatory imperative” in the last 24 months.

Three forces have raised the stakes:

NAIC Model Law adoption is now broad. The NAIC Insurance Data Security Model Law (#668) has been adopted in 26 US states as of early 2026, with the NAIC Standards for Safeguarding Customer Information (Model Law #672) referenced in most state DOI examination handbooks. State DOIs increasingly ask, during examinations, for documented evidence that migration preserved PII handling controls and produced a complete audit trail.

NIST CSF 2.0 is the de facto baseline. The NIST Cybersecurity Framework 2.0, updated in 2024, is now referenced by most US state DOI examinations as the baseline expectation. Migrations that cannot map their controls to NIST CSF functions (Identify, Protect, Detect, Respond, Recover, Govern) are at higher risk of negative findings.

NY DFS 23 NYCRR 500 raised the bar. For carriers writing business in New York, 23 NYCRR 500 requires evidence of cybersecurity controls including encryption, access controls, audit logging, and incident response - all of which apply to migration in transit. New York’s enforcement actions have, from what I have observed across the carriers I work with, set the de facto floor for the rest of the US market.

This guide is the playbook I would walk through with you on a Migration Architecture Review focused on the security workstream. It is written for CIOs, enterprise architects, COOs, and compliance leads at US P&C carriers between $500M and $5B GWP. For the broader strategic picture of why insurance data migration is uniquely hard, insurance data migration challenges is the pillar guide; this article focuses on the security and compliance workstream specifically.

Data security during insurance data migration - direct answer

Data security during insurance data migration is the set of technical, procedural, and contractual controls that protect policyholder PII, claim data, financial records, and regulatory artefacts from breach, loss, or unauthorized access during transit from a legacy core system to a target system. For US P&C carriers, the controls must satisfy NAIC Model Law #668/#672, NIST Cybersecurity Framework 2.0, state DOI examination expectations, and (where applicable) NY DFS 23 NYCRR 500. The controls split into ten categories: encryption (at rest, in transit, in compute), access controls and least privilege, audit trail per record, data lineage as a regulatory artefact, vendor security (SOC 2 Type II, ISO 27001), PII/PHI minimization in non-production environments, incident response for cutover, regulatory continuity through cutover, data residency, and post-migration validation.

The short version of the security gate:

• Encrypt data everywhere - at rest, in transit, and increasingly in compute.
• Maintain a per-record audit trail for state DOI examination.
• Treat data lineage as a regulatory artefact, not an internal-only document.
• Require SOC 2 Type II from every vendor touching production data.
• Pre-write the incident response playbook for cutover weekend.
• Validate post-migration that controls remained intact, with written sign-off from Compliance.

The next sections expand each into a working playbook.

The regulatory landscape - NAIC, NIST, NY DFS, state DOI

Most CIOs I work with can name “NAIC” and “GDPR” and “HIPAA” and “CCPA” - but the question is whether the migration team has actually mapped controls to specific Model Law sections, NIST CSF subcategories, and NY DFS provisions. In my experience, this mapping is the single most underestimated piece of pre-migration security work.

NAIC Model Law #668 - Insurance Data Security Model Law

NAIC Model Law #668 is the framework for insurance-industry cybersecurity in the US. As of early 2026, 26 states have adopted it (Alabama, Connecticut, Delaware, Hawaii, Indiana, Iowa, Kentucky, Louisiana, Maine, Maryland, Michigan, Minnesota, Mississippi, New Hampshire, North Dakota, Ohio, Oklahoma, Pennsylvania, Rhode Island, South Carolina, Tennessee, Vermont, Virginia, West Virginia, Wisconsin, Wyoming - the list updates; check your state DOI for current adoption).

The migration-relevant sections of #668 require carriers to:

• Develop, implement, and maintain a written information security program.
• Conduct risk assessments of internal and external threats.
• Implement security controls based on the risk assessment.
• Encrypt nonpublic information at rest and in transit.
• Implement multi-factor authentication for access to information systems.
• Train employees on cybersecurity awareness.
• Oversee third-party service providers - including migration vendors.
• Establish a written incident response plan.

Each of these has a direct application to the migration program. The “third-party service provider oversight” requirement in particular is what most carriers underestimate when bringing in a migration vendor.

NAIC Model Law #672 - Standards for Safeguarding Customer Information

#672 is the older standard, but still operationally relevant for the safeguarding of customer information. State DOI examination handbooks reference both #668 and #672. For migration, the most relevant #672 requirements are around administrative, technical, and physical safeguards - the migration plan should map controls to all three categories.

NIST CSF 2.0 - the de facto baseline

NIST CSF 2.0, updated in February 2024, expanded the framework to six functions: Govern, Identify, Protect, Detect, Respond, Recover. The Govern function is new in 2.0 and is what most insurance migration programs miss. For migration security, the mapping is:

• Govern. Migration program charter signed at CEO level, with named security accountability.
• Identify. Data source inventory with PII / PHI classification, third-party risk assessment.
• Protect. Encryption, access controls, training, secure SDLC.
• Detect. Audit logging, real-time monitoring during cutover.
• Respond. Incident response playbook for cutover weekend (Section 8).
• Recover. Rollback plan, post-incident analysis, communication template.

State DOI examinations increasingly ask for the NIST CSF 2.0 mapping. Migrations that cannot produce it are at higher risk of negative findings.

NY DFS 23 NYCRR 500 - the strictest US framework

For carriers writing business in New York, 23 NYCRR 500 sets the strictest US standard. Migration-relevant requirements include encryption of nonpublic information in transit and at rest, multi-factor authentication for privileged access, continuous monitoring or annual penetration testing, written incident response plan with 72-hour notification, third-party service provider security program, and CISO-level annual certification.

From what I have observed at carriers, those writing in New York treat 23 NYCRR 500 as the baseline. Carriers writing only in non-NY states often use it as a target standard anyway, because the NAIC trajectory is converging on similar requirements.

State DOI examination - what they actually ask for

State DOI examination scope varies, but the migration-relevant questions I have seen examiners ask include: per-record audit trail for PII migrated, written third-party migration vendor risk assessment, evidence of encryption controls during cutover, documentation of incident response plan, evidence of access control review for migration team members, and post-migration validation of regulatory continuity (Schedule P, rate filings, Schedule F). For the broader regulatory readiness picture, how to prepare for insurance data migration covers the pre-migration regulatory documentation framework.

The 10-control framework for migration security

The 10-control framework I use with carriers maps regulatory expectations to operational controls for data security during insurance data migration programs. Each control has an owner, an artefact, and a measurable success criterion. The framework sits alongside the broader insurance data migration challenges covered in the pillar guide - security is one of those challenges, and the practices in this article are the operational answer. Score each control before entering execution; anything red is a security gate that should block program kickoff.

A migration that scores green on all 10 controls is one I would let into execution. Anything below 7 of 10 green is a program that needs more security work before kickoff.

The next sections go deep on the highest-impact controls: encryption (Section 5), audit trail (Section 6), vendor security (Section 7), and incident response (Section 8).

Encryption at rest, in transit, and in compute

Encryption is the baseline. Every NAIC, NIST, and NY DFS framework references it. The question is not whether to encrypt - it is how, with what key management, and across which compute boundaries.

Encryption at rest

For data at rest, the baseline is AES-256 or equivalent, applied at the storage layer with documented key management. For mid-tier P&C carriers, I recommend:

• Source system data encrypted at rest before migration begins. If the legacy system does not encrypt, that is a finding on its own.
• Staging environments encrypted at rest with separate keys from production.
• Target system encrypted at rest from day one of migration.
• Key management via hardware security module (HSM) or equivalent cloud KMS.
• Key rotation policy documented and tested.

Encryption in transit

For data in transit, the baseline is TLS 1.2 minimum, TLS 1.3 preferred. Every connection between source, staging, and target should terminate in TLS, with certificate pinning where the architecture supports it. The specific controls I look for:

• TLS 1.2+ on every network connection.
• Mutual TLS (mTLS) between migration tool and source/target systems.
• VPN or private network connection for source-to-cloud-staging traffic, where the source is on-premise.
• No data crossing public internet in cleartext, ever.

Encryption in compute (the 2026 standard)

The new dimension in 2026 is encryption in compute - the principle that data should be encrypted even while being processed, using confidential computing primitives (Intel SGX, AMD SEV, AWS Nitro Enclaves, Azure Confidential Computing). For most mid-tier P&C carriers, encryption in compute is still emerging - but for migrations involving sensitive PII or PHI, it is increasingly something state DOI examinations ask about. I recommend planning for it now, even if you do not deploy it on this migration.

Key management as a regulatory artefact

The key management policy is, from what I have seen at state DOI examinations, the document examiners most often ask for after the audit trail. It should specify:

• Who owns the keys (carrier, not vendor).
• How keys are stored (HSM, cloud KMS).
• How keys are rotated (schedule, frequency).
• How keys are revoked (offboarding process).
• How key access is logged.

For the broader minimization-of-downtime picture, minimizing downtime during insurance data migration covers how to balance encryption overhead against cutover window constraints.

Audit trail and data lineage as regulatory artefacts

This is the control that the CIO in Section 1 was missing. State DOIs increasingly treat the per-record audit trail and the data lineage register as required artefacts - not internal documentation, but examination-ready evidence.

Per-record audit trail

For every PII or PHI record migrated, the audit trail should capture:

• Source system identifier (table, primary key).
• Target system identifier (table, primary key).
• Transformation applied (one-to-one, enum mapping, field calculation, derivation).
• Timestamp of migration.
• Migration job identifier (which run produced this record).
• Validation status (passed, failed, exception with disposition).

For a mid-tier P&C carrier with 50 million records, the audit trail itself is a multi-terabyte dataset. It must be retained for the regulatory retention window (typically 7-10 years for insurance) and must be queryable on demand. Carriers that build this as an afterthought find out at examination time that “queryable on demand” is harder than they planned for.

Data lineage register

The data lineage register is the field-level version of the audit trail. For every field in the target system, the register documents:

• Source field (system, table, column).
• Transformation rule (with the business rule, not just the code).
• Business owner (the person who owns the rule).
• Regulatory tag (ACORD AL3 field, NAIC reporting field, state DOI filing field, PII, PHI, none).
• Last validated date.

The register is the artefact a state DOI examiner asks for when verifying that a specific field used in a rate filing was migrated correctly. Without it, the examiner has to take the carrier’s word for it - which, from what I have observed, examiners are increasingly unwilling to do.

Audit trail as an internal control too

Beyond regulatory use, the audit trail is the carrier’s own control against silent migration errors. If a field is wrong in production three months after migration, the audit trail is how you trace back to which migration job introduced the error and what the source value was. Without it, you are debugging blind.

I have seen carriers build audit trail capability into their migration tool from day one. I have also seen carriers add it after a state DOI finding. The first approach costs roughly 3-5% of migration program effort. The second approach costs 25-40% in remediation.

Vendor security requirements - SOC 2, ISO 27001, contract clauses

NAIC #668 explicitly requires carriers to oversee third-party service providers, including migration vendors. From what I have observed across carrier programs, this is the requirement most often signed off as “vendor said yes” without the documentation to back it up. The third-party oversight question is also one of the most common insurance data migration challenges covered in the pillar guide - if you have not solved it operationally, the contract clause alone is not enough.

What to require from every migration vendor

The minimum vendor security documentation I would require before signing:

• SOC 2 Type II report, current within 12 months. Type I is not enough; Type II shows operating effectiveness over a 6-12 month period.
• ISO 27001 certification (preferred but not always required).
• Penetration test report within the last 12 months, with executive summary disclosable.
• Vendor cybersecurity policy documented and current.
• Sub-processor list, with each sub-processor evaluated separately.
• Data Processing Agreement (DPA) signed before any production data movement.
• Incident notification timelines matching or exceeding 72-hour standard (NY DFS).
• Right-to-audit clause in the master services agreement.
• Data residency commitments documented.
• Exit and data return clauses with specific timelines.

Decerto’s security posture (transparency disclosure)

For full transparency on the vendor side: Decerto operates under SOC 2 Type II controls and ISO 27001 certification, maintains annual penetration testing, and signs DPA terms compatible with NAIC #668 third-party oversight. When evaluating Decerto as a migration vendor, we provide these documents on request. The same standard should apply to every vendor on the migration shortlist - including the Decerto Data Migrator platform engagement and any competing platform.

Where vendor security gaps actually show up

In my experience, the gaps that produce state DOI findings are not “the vendor has no SOC 2.” They are subtler:

• SOC 2 covers the vendor’s own systems but not the configuration deployed at the carrier.
• Sub-processors (the vendor’s vendors) are not evaluated separately.
• The DPA is signed but not enforced in practice.
• Migration team members have privileged access that was never reviewed.
• The right-to-audit clause exists but the carrier never exercises it.

Each of these is a real finding I have seen at carriers. The remediation is harder than the prevention. Vendor security oversight is operational work, not a contract signature.

Incident response during cutover weekend

The cutover weekend is when the migration security posture is most exposed. Source data is being read at high volume, staging data is in active processing, target data is being written, and the migration team has elevated access. If a security incident occurs during this window, the incident response plan needs to be pre-written and tested - not improvised at 3 a.m.

The pre-cutover incident response readiness checklist

Before cutover weekend begins:

• Incident response playbook is written, reviewed, and signed by CISO and COO.
• All migration team members have completed cybersecurity awareness training within the last 90 days.
• Privileged access for migration team is time-bound and revoked at H+72 post-cutover.
• Out-of-band communication channels established (Signal, secure phone tree).
• 24/7 SOC coverage confirmed for cutover weekend.
• Vendor incident response team contact details verified.
• Regulator notification template pre-written for 72-hour disclosure if needed.

Incident scenarios specific to cutover

The four scenarios I would pre-plan for:

Scenario 1 - Suspected data exfiltration during cutover. Unusual outbound traffic from migration staging environment. Playbook: isolate, capture, escalate to CISO within 15 minutes, evaluate whether to continue or pause cutover. The pause decision belongs to the named CIO or delegate, not the migration team.

Scenario 2 - Reconciliation variance suggests data corruption. Reconciliation report shows policy count off by more than tolerance. Playbook: pause load, investigate root cause, decide rollback vs continue. Rollback decision criteria documented in advance (see insurance data migration best practices Section 6).

Scenario 3 - Vendor reports incident in their environment during cutover. Vendor SOC reports anomaly. Playbook: vendor must notify within 1 hour, carrier evaluates impact on in-flight migration, decision on continue/pause within 2 hours.

Scenario 4 - Regulator notifies carrier of related incident. State DOI, NY DFS, or other regulator notifies carrier of an incident affecting them or a related party. Playbook: pause cutover until impact assessed, written disposition signed by CISO and CIO before resuming.

In my experience, the carriers that handle cutover security well are not the ones with the fanciest tooling. They are the ones whose CISO has personally signed the incident response playbook and can name the four scenarios from memory.

Common security gaps that cause findings

I will state this directly: the security gaps below are the ones I have personally seen produce state DOI findings or near-misses at mid-tier P&C carriers. They are not theoretical.

Security gap 1: Encryption only in transit, not at rest in staging

Carriers encrypt source-to-staging traffic with TLS, then dump the staging environment to an unencrypted disk for processing speed. Staging data is production-equivalent PII. Encryption in transit without encryption at rest in staging is incomplete.

Security gap 2: Migration team has standing privileged access

Migration team members are granted production-equivalent access at the start of the program and retain it 6-12 months. The access review never happens. State DOI examiners ask for the access review log and find it does not exist.

Security gap 3: Audit trail captured but not retained

The migration tool produces an audit log during the run, then the log is overwritten by the next run. The 7-10 year retention requirement is not met. This is the most common version of the Section 1 anecdote.

Security gap 4: Vendor SOC 2 not re-validated annually

The carrier collected SOC 2 at vendor selection. Two years later, the SOC 2 is expired and no one renewed it. NAIC #668 third-party oversight is technically not satisfied.

Security gap 5: Test environments use real production PII

The team copies production data to test environments “to get realistic test results.” PII appears in test, dev, QA, and pre-prod environments without masking. This is a finding under NAIC #668, NY DFS 500, and most state DOI standards.

Security gap 6: Incident response playbook written but never tested

The playbook exists. No one has run it through a tabletop exercise. The first time it gets used is the actual incident. Predictably, gaps surface that should have surfaced in rehearsal.

Security gap 7: Data lineage as internal-only documentation

The data lineage register exists in a Confluence page that the migration team uses for their own reference. The format is not examination-ready. State DOI asks for it; the carrier scrambles to format it under time pressure.

Security gap 8: PII migrated to cloud staging in a non-compliant region

The carrier writes in 12 states with varied data residency expectations. The migration vendor’s default cloud region is in a different geography. The carrier discovers this at month 3 of execution.

Security gap 9: Backup of legacy not kept through migration

The carrier decommissions legacy backups too early in the cutover process. If a rollback is needed beyond the planned window, the source state is not restorable. This is both a security and an operational continuity gap.

Security gap 10: Compliance brought in at execution, not readiness

This is the recurring pattern across all 9 gaps above. Compliance must be in the program from week 1 of readiness (covered in how to prepare for insurance data migration and in the broader insurance data migration challenges pillar guide). Bringing Compliance in at month 9 produces a retrofit that costs more and looks worse to examiners than a properly designed control set.

Decerto Generali Group Poland - security-first migration tooling

The reference deployment that most directly illustrates how a security-first migration tool is designed is the Generali Group Poland data migration delivered by Decerto.

The setup

When Generali Group Poland acquired another insurance company, the migration moved sensitive policy, claim, and customer data from the acquired company’s IT architecture into Generali’s infrastructure. The acquired data was, in Generali’s own published case study, of poor quality - requiring validation, correction, and standardization before migration. At the same time, the security posture had to be maintained throughout, with no PII exposure during the migration window.

Security-first tool design

Three security-first design choices are visible in how Decerto built the dedicated migration tool for this project:

Custom validation built into the tool. Rather than apply generic ETL with bolt-on validation, the migration tool included built-in validation for completeness and accuracy at the data entry point. Records flagged for correction never proceeded to the target system in a partial state - eliminating the class of error where bad data ends up in production and is discovered at examination.

Transformation and reporting in one tool. The same tool handled the data transformation to Generali’s target model and produced comprehensive migration reports for tracking and verification. The audit trail was a first-class output, not an afterthought. This is the practice from Section 6 in production.

Single weekend cutover with parallel operations. The actual migration ran over a single weekend, with both teams (Generali and Decerto) operating as a single unit. The compressed cutover window reduced the time during which migration access was elevated - which is the practice from Section 8 in production.

The published outcomes

From Generali’s published case study: the balance of financial transactions remained intact, no data loss occurred, and data quality improved through validation and correction. For a US mid-tier P&C carrier asking whether security-first migration tooling is worth the premium versus retrofitting security onto generic ETL - the Generali reference is the most direct public answer Decerto can point to.

The same approach scales to mid-tier P&C carriers in the $500M-$5B GWP range. The Migration Architecture Review (in Section 12) is where we translate the security framework to your specific regulatory environment.

‍

Frequently asked questions

How do you keep data secure during insurance data migration?

Implement the 10-control framework from Section 4: encryption (at rest, in transit, in compute), access controls with least privilege, per-record audit trail, data lineage register, vendor SOC 2 Type II oversight, PII minimization in non-production, pre-written incident response playbook, regulatory continuity through cutover, documented data residency, and written post-migration validation. Each control has an owner and a measurable success criterion.

What NAIC rules apply to insurance data migration security?

NAIC Model Law #668 (Insurance Data Security Model Law) is the primary framework, adopted in 26 US states as of early 2026. NAIC Model Law #672 (Standards for Safeguarding Customer Information) is the older companion standard, still referenced by state DOI examination handbooks. Migration-relevant requirements include written information security program, encryption at rest and in transit, multi-factor authentication, third-party service provider oversight, and written incident response plan.

How is PII protected during data migration in insurance?

PII protection during migration combines encryption (AES-256 at rest, TLS 1.2+ in transit, increasingly encryption in compute), access controls with multi-factor authentication and least privilege, per-record audit trail for regulatory traceability, masking or synthetic data in non-production environments, and documented data residency. The controls should be mapped to NAIC #668, NIST CSF 2.0, and (where applicable) NY DFS 23 NYCRR 500.

What is zero-trust migration architecture for insurance data security?

Zero-trust migration architecture is the pattern that treats every component of the migration pipeline as untrusted by default, requiring authentication and authorization at every boundary. For insurance migration, this means mutual TLS between source, staging, and target; time-bound privileged access for migration team members; continuous logging and monitoring; and encryption in compute where supported by the target architecture.

What audit trail is required for insurance data migration?

For each PII or PHI record migrated, the audit trail must capture source identifier, target identifier, transformation applied, timestamp, migration job identifier, and validation status. The trail must be retained for the regulatory retention window (typically 7-10 years for insurance) and must be queryable on demand for state DOI examinations. Building it as an afterthought costs 25-40% in remediation; building it in costs 3-5% of program effort.

What encryption standard is required for insurance data migration?

The baseline is AES-256 (or equivalent strength) for data at rest and TLS 1.2 minimum (TLS 1.3 preferred) for data in transit. NAIC Model Law #668 requires encryption of nonpublic information at rest and in transit. NY DFS 23 NYCRR 500 requires similar with stricter enforcement. Encryption in compute (Intel SGX, AMD SEV, AWS Nitro Enclaves) is emerging as a 2026 expectation for sensitive workloads.

What vendor security requirements should I impose on a migration vendor?

At minimum: SOC 2 Type II report current within 12 months, ISO 27001 certification (preferred), recent penetration test report, vendor cybersecurity policy, sub-processor list with separate evaluation, signed Data Processing Agreement, 72-hour incident notification commitment, right-to-audit clause, data residency commitments, and exit/data return clauses. These should be operational, not just contractual.

How long should insurance data migration audit trails be retained?

Typically 7 to 10 years for US P&C insurance, matching the standard policy and claims retention requirements under NAIC retention rules and state-specific DOI expectations. Some lines (workers’ comp, long-tail liability) may require longer. The retention strategy should be documented in the data lineage register and aligned with the carrier’s broader records retention policy.

‍

Talk to Decerto about secure insurance data migration

If you read one section of this article on data security during insurance data migration, I would point you here.

State DOI examinations of post-migration insurance environments have, from what I have seen at the carriers I work with, increased in depth every year since 2022. The carriers that designed security in from week 1 of readiness are passing examinations clean. The carriers that retrofitted security in execution are managing findings. The cost difference is 5-10x.

A free 30-minute Migration Architecture Review with me (Janusz Januszkiewicz). Vendor-neutral. I bring 15+ years of insurance migration experience plus a senior Decerto architect. You bring your current state architecture and your top three security questions. We leave with a preliminary score across the 10-control framework, plus a written list of the highest-risk gaps to close before execution.

Decerto’s Data Migrator platform and migration services are designed for mid-tier P&C carriers in the $500M-$5B GWP range with US regulatory exposure (NAIC, state DOI, NY DFS where applicable). For sub-$250M GWP carriers, the security framework in this article is the right reference but the vendor cost may be over-scaled - a smaller engagement is often the right call. For $5B+ enterprise carriers running on Guidewire ClassicSuite, Guidewire’s own services partners are the better technical fit. We are not the right answer for every carrier; we are honest about which carriers we serve well.

Climax. The 10-control framework, the encryption standards, the audit trail requirements, and the incident response playbook in this article are the same artefacts used on the Generali Group Poland migration, on the Warta agent platform consolidation, on the BNP Paribas Cardif claims handling centralization, and on US mid-tier engagements that remain under NDA. The framework is not theory. It is the working checklist that gets carriers through examination clean.

Sources and citations

1. NAIC. (2024). Insurance Data Security Model Law (#668). National Association of Insurance Commissioners.
2. NAIC. (2024). Standards for Safeguarding Customer Information (Model Law #672). National Association of Insurance Commissioners.
3. NIST. (2024). Cybersecurity Framework 2.0. National Institute of Standards and Technology.
4. NIST. (2024). Special Publication 800-53 Rev. 5 - Security and Privacy Controls.
5. NY DFS. (2024). 23 NYCRR 500 - Cybersecurity Requirements for Financial Services Companies. New York Department of Financial Services.
6. ACORD. (2025). ACORD Standards - AL3 and XML reference documentation.
7. AICPA. (2024). SOC 2 Type II - Trust Services Criteria.
8. ISO. (2022). ISO/IEC 27001:2022 - Information Security Management.
9. McKinsey & Company. (2025). State of Insurance 2025 - Cybersecurity in P&C.
10. Deloitte. (2025). 2026 Insurance Industry Outlook - Cyber and Regulatory.