Global control assurance and statutory evidence operations

DORA entered into force in January 2025, establishing binding requirements for ICT risk management, incident reporting, resilience testing, and third-party risk management across the EU financial sector. The regulation applies to virtually all regulated financial entities — banks, insurers, investment firms, payment institutions, crypto-asset service providers — and to the critical ICT third-party service providers that support them. The first year of enforcement has been a learning period for both the industry and supervisors, and the initial supervisory findings provide invaluable insight into how regulators interpret and enforce the regulation's requirements.

ICT third-party risk management findings

Third-party risk management is the DORA pillar generating the most supervisory findings. Article 28 requires financial entities to maintain a thorough register of all ICT third-party arrangements, conduct risk assessments of critical and important functions outsourced to ICT providers, and implement contractual provisions ensuring the entity's ability to monitor, audit, and terminate third-party arrangements when necessary. Supervisors are finding widespread deficiencies across all three requirements.

The ICT third-party register — a thorough inventory of all technology providers, the services they deliver, the criticality of those services, and the contractual terms governing the arrangement — is incomplete at most inspected institutions. Many organizations maintain partial inventories that cover major cloud providers and managed-service relationships but omit SaaS applications, data providers, and technology components embedded within larger vendor platforms. The register's incompleteness undermines the entity's ability to assess concentration risk, identify single points of failure, and plan for provider disruption.

Contractual compliance is another persistent finding. DORA specifies mandatory contractual provisions that must be included in agreements with ICT third-party providers, including audit rights, incident notification obligations, data-access guarantees, and exit-strategy provisions. Supervisors report that many existing contracts predate DORA and do not include the required provisions. Renegotiating contracts with major technology providers is a protracted process, and many financial entities have not completed the renegotiation cycle despite the regulation being enforceable since January 2025.

Concentration risk assessment — the evaluation of the financial entity's dependence on a small number of critical ICT providers — receives attention as a systemic-risk concern. Supervisors observe that the entire European financial sector's concentration on a handful of hyperscale cloud providers creates correlated risk that individual entity-level assessments do not adequately capture. The designation framework for critical ICT third-party providers under DORA Article 31 is expected to produce the first designations in 2026, subjecting designated providers to direct regulatory oversight by the European Supervisory Authorities.

Incident classification and reporting gaps

DORA's incident-reporting requirements mandate that financial entities classify ICT-related incidents according to defined criteria — including duration, geographic scope, number of affected clients, data integrity impact, and criticality of affected services — and report major incidents to their competent authority within specified timeframes. The initial reporting deadline is four hours for an initial notification, followed by intermediate and final reports at defined intervals.

Supervisors find that incident-classification processes are inconsistent across the sector. The classification criteria defined in the DORA Regulatory Technical Standards require organizations to evaluate incidents against multiple dimensions simultaneously, and the multi-dimensional assessment challenges organizations that previously classified incidents using simpler severity scales. Several supervised entities have been cited for underclassifying incidents — applying severity ratings that result in non-reporting when the incident's actual characteristics meet the major-incident threshold.

The four-hour initial notification timeline has proven operationally challenging. Organizations with 24/7 security operations centers can generally meet the deadline, but smaller institutions with limited after-hours staffing struggle to detect, classify, and report incidents within the window. The challenge is compounded when the incident affects multiple regulatory jurisdictions, requiring parallel notifications to multiple competent authorities with potentially different reporting formats.

Incident taxonomy standardization across the financial sector remains a work in progress. The European Supervisory Authorities are refining the incident-reporting templates and taxonomy based on the first year's reporting experience, aiming to reduce interpretation ambiguity and improve cross-sector comparability of incident data. Financial entities should monitor the evolving guidance and update their classification procedures accordingly.

Digital operational resilience testing

DORA requires financial entities to implement a digital operational resilience testing program proportionate to their size and risk profile. All entities must conduct basic ICT testing including vulnerability assessments and scenario-based testing. Entities identified as significant must additionally conduct threat-led penetration testing (TLPT) at least every three years, using methodologies aligned with the TIBER-EU framework.

Supervisory findings indicate that basic resilience testing programs are generally in place but often lack the scope and depth that DORA requires. Vulnerability assessments that cover only internet-facing systems, scenario tests that address only a narrow set of threats, and testing programs that do not cover the entity's full ICT estate including third-party-provided services fall short of the regulation's requirements.

TLPT programs are at an earlier stage of maturity. The regulation requires that threat-led penetration tests simulate realistic attack scenarios based on current threat intelligence, conducted by qualified independent testers against the entity's live production environment. Many significant entities have not yet completed their first DORA-compliant TLPT, citing the complexity of procurement, scope definition, and operational-risk management for live-environment testing. The European Supervisory Authorities are working with national competent authorities to increase the supply of qualified TLPT providers and to harmonize testing standards across member states.

Testing results must feed back into the entity's ICT risk management framework, driving remediation of identified vulnerabilities and improvement of resilience capabilities. Supervisors are checking that this feedback loop is operational — that testing findings result in documented remediation actions, that remediation is tracked to completion, and that subsequent tests verify the effectiveness of remediation measures. The absence of a closed-loop testing-to-remediation process is a common finding.

Proportionality and smaller entity challenges

DORA's proportionality principle allows requirements to be applied with regard to the entity's size, nature, scale, and complexity. However, supervisors are interpreting proportionality narrowly: the principle permits simplification of processes and documentation, not exemption from substantive requirements. Smaller financial entities that assumed proportionality would excuse them from third-party risk management, incident reporting, or resilience testing are receiving corrective findings.

The compliance burden is particularly acute for smaller institutions that lack dedicated ICT risk management functions. Payment institutions, electronic money institutions, and smaller investment firms often operate with IT teams of fewer than ten people, for whom the documentation, process, and testing requirements of DORA represent a significant operational overhead. Industry associations have called for regulatory guidance that provides concrete examples of proportionate compliance for smaller entities, and the European Supervisory Authorities have indicated that such guidance is forthcoming.

Managed service providers that serve multiple smaller financial entities are positioning DORA compliance as a managed service, offering pre-built incident-classification workflows, third-party risk management tools, and resilience-testing programs that smaller entities can adopt without building internal capability from scratch. This approach follows the regulation's intent — the risk-management capability must exist, but it can be delivered through external support rather than internal headcount.

Recommended actions for financial entities

Review your ICT third-party register for completeness. Ensure that every technology provider — including SaaS applications, data feeds, and embedded technology components — is cataloged with accurate criticality assessments and contractual-compliance status. Initiate contract renegotiations for arrangements missing DORA-mandated provisions.

Validate your incident-classification process against the DORA Regulatory Technical Standards. Conduct tabletop exercises simulating incidents at different severity levels and verify that your classification produces the correct regulatory-reporting outcome. Test the four-hour notification timeline under realistic conditions including after-hours scenarios.

Assess your digital operational resilience testing program's scope and depth against DORA requirements. Ensure that testing covers the full ICT estate, includes scenario-based testing informed by current threat intelligence, and feeds findings back into remediation processes with tracking and verification.

If you are a significant entity that has not yet completed a DORA-compliant TLPT, begin procurement and planning immediately. The three-year TLPT cycle means that delays now will create compliance gaps that are difficult to recover from later.

Forward analysis

DORA's first enforcement wave confirms that the regulation is being implemented and enforced with seriousness. Financial entities that treated DORA as a paper-compliance exercise are discovering that supervisors assess operational capability, not just documentation. The findings reinforce a message that applies to all regulatory compliance: the value of a governance framework lies in its operational effectiveness, not in the quality of the policy documents sitting on the compliance team's shelf.

The regulatory trajectory is toward increased scrutiny as supervisory experience accumulates and enforcement maturity develops. Financial entities that achieve genuine operational resilience — not just documented compliance — will be better positioned for both regulatory relationships and real-world ICT disruptions. The investment in operational capability pays dividends in both contexts.

The HIPAA Security Rule has not been substantively updated since 2013, a period during which the healthcare sector has become the most-targeted industry for ransomware attacks, the volume of electronically stored protected health information has grown exponentially, and the technology environment has transformed through cloud adoption, telehealth expansion, and connected medical devices. The proposed modernization rule acknowledges that the original rule's flexibility — its reliance on "addressable" specifications that allowed covered entities to adopt alternative measures or decline implementation based on risk assessment — has been exploited by organizations seeking to minimize security investment. The proposed rule replaces flexibility with mandates, creating enforceable minimum security standards that all covered entities and business associates must meet.

Elimination of the addressable-required distinction

The current HIPAA Security Rule divides implementation specifications into "required" and "addressable" categories. Required specifications must be implemented as written. Addressable specifications allow covered entities to assess whether the specification is a reasonable and appropriate safeguard in their environment and, if not, to implement an alternative measure or document why the specification is not applicable. In practice, the addressable category has been used by some organizations to justify not implementing fundamental security controls like encryption, citing cost, complexity, or operational disruption.

The proposed rule eliminates the addressable category entirely. All implementation specifications become mandatory. The rule's preamble explicitly acknowledges that the addressable framework was abused: HHS cites enforcement investigations where organizations used addressable status to avoid implementing encryption on laptops, portable storage devices, and email systems containing ePHI, resulting in preventable data breaches affecting millions of individuals.

The elimination of addressable specifications represents the most significant structural change in the rule's history. Organizations that have documented risk-based justifications for not implementing specific security controls must now implement those controls or accept noncompliance. The compliance baseline rises substantially, particularly for smaller healthcare providers and business associates that have historically operated with minimal security infrastructure.

A limited exception framework replaces the addressable concept. Organizations may request temporary implementation deferrals for specific requirements through a formal waiver process administered by the HHS Office for Civil Rights. Waivers require documented technical justification, a remediation timeline, and compensating controls during the deferral period. The waiver process is designed to be rigorous enough to prevent the kind of systematic avoidance that the addressable framework enabled while acknowledging that legitimate implementation challenges exist.

Mandatory encryption requirements

The proposed rule mandates encryption of all ePHI at rest and in transit, using cryptographic standards specified by NIST. At-rest encryption must use AES-256 or equivalent, applied to all storage media including databases, file systems, portable devices, backup media, and removable storage. In-transit encryption must use TLS 1.2 or higher for all network communications involving ePHI, including internal network traffic between systems within the same facility.

The internal-network encryption requirement is a significant expansion from current practice. Many healthcare organizations encrypt ePHI in transit over public networks but transmit it in cleartext within their internal networks, relying on perimeter security to protect internal communications. The proposed rule rejects this approach, citing the frequency of insider threats and lateral-movement attacks that exploit unencrypted internal traffic. The requirement effectively mandates a zero-trust approach to network encryption within healthcare environments.

Implementation timelines acknowledge the operational complexity of universal encryption deployment. Covered entities have 24 months from the final rule's effective date to achieve full compliance with encryption requirements. Business associates have the same timeline but face additional obligations to certify encryption compliance to their covered-entity partners. The timeline is aggressive given the scope of the requirement, particularly for organizations with large installed bases of legacy medical devices and clinical systems that may not support modern encryption standards.

Legacy-device exemptions are narrowly defined. Medical devices that cannot support encryption due to hardware or firmware limitations may operate under a compensating-controls framework that requires network segmentation, enhanced monitoring, and documented risk acceptance by organizational leadership. The exemption is time-limited and requires organizations to present remediation plans for replacing non-compliant devices. HHS estimates that this exemption will apply to approximately 15 percent of connected medical devices currently in use.

Multi-factor authentication mandate

The proposed rule requires multi-factor authentication for all user access to systems containing ePHI. This includes clinical applications (electronic health records, clinical decision support, radiology systems), administrative systems (billing, scheduling, claims processing), and infrastructure systems (servers, databases, network equipment) that store or process protected health information.

MFA implementation must use at least two factors from different categories: knowledge (passwords, PINs), possession (hardware tokens, mobile devices), or inherence (biometrics). The rule specifically discourages SMS-based one-time passwords due to documented vulnerabilities in the telecommunications infrastructure and recommends FIDO2-compliant authenticators or hardware security keys for high-privilege accounts.

Clinical-workflow considerations receive specific attention. HHS acknowledges that MFA can introduce friction in clinical environments where rapid system access is critical for patient care. The proposed rule permits risk-based MFA exemptions for specific clinical workflows — such as emergency-department workstations and operating-room systems — provided that compensating controls including session timeouts, proximity-based authentication, and enhanced audit logging are implemented. The exemption is designed for genuine clinical-urgency scenarios rather than general clinical convenience.

The MFA requirement applies to remote access, local access, and privileged access equally. Organizations that have implemented MFA only for VPN connections or remote-access portals must extend coverage to all systems containing ePHI, including workstations, clinical applications, and administrative platforms. The universal scope significantly expands the deployment footprint beyond what many organizations have implemented to date.

Recovery time objectives and resilience requirements

The proposed rule establishes a 72-hour maximum recovery time objective (RTO) for critical systems containing ePHI. This is the first time HIPAA has specified a quantitative recovery-time standard, replacing the current rule's general requirement for contingency plans with a measurable, enforceable recovery target.

Critical systems are defined as those whose unavailability would directly impair patient care, prevent access to medical records needed for treatment decisions, or interrupt essential administrative functions such as medication dispensing, laboratory reporting, or clinical communications. Each covered entity must identify its critical systems, document recovery procedures, and demonstrate through annual testing that the 72-hour RTO can be met under realistic disaster scenarios including ransomware attacks.

Backup requirements are strengthened. Organizations must maintain immutable backups of all ePHI stored in environments that are logically and physically separated from production systems. Backup integrity must be verified through regular restoration testing, and backup recovery procedures must be documented in sufficient detail for execution by alternate personnel. The immutable-backup requirement directly addresses the ransomware tactic of encrypting both production data and backup systems to maximize use.

Annual contingency-plan testing must include a full-scale recovery exercise simulating the unavailability of the organization's primary data center or cloud infrastructure. Tabletop exercises alone do not satisfy the testing requirement; HHS requires functional recovery demonstrations that validate end-to-end restoration capability including application recovery, data integrity verification, and user-access restoration within the 72-hour window.

Penetration testing and vulnerability management

The proposed rule introduces mandatory annual penetration testing for all covered entities and business associates, conducted by qualified independent assessors. Penetration tests must cover external-facing systems, internal network infrastructure, web applications, and wireless networks. Social-engineering testing — including phishing simulations targeting employees with ePHI access — is recommended but not required in the initial rule.

Vulnerability scanning must be conducted at least quarterly for all systems containing ePHI, with critical vulnerabilities remediated within 30 days and high-severity vulnerabilities remediated within 60 days. The remediation timelines are mandatory and enforceable, replacing the current rule's general requirement for risk management with specific, measurable obligations.

Findings from penetration tests and vulnerability scans must be documented, tracked to remediation, and reported to organizational leadership. HHS expects that penetration-test findings will inform the organization's risk assessment and drive security-investment prioritization. Organizations that identify critical vulnerabilities through penetration testing but fail to remediate them within the specified timelines face enforcement action regardless of whether the vulnerabilities are exploited.

Compliance timeline and industry impact

The proposed rule is subject to a 60-day public comment period, after which HHS will review comments and publish a final rule. Covered entities and business associates will have 24 months from the final rule's effective date to achieve full compliance, with limited extensions available through the formal waiver process for specific requirements that present documented implementation challenges.

The compliance cost impact is substantial. HHS estimates that the proposed rule will cost the healthcare industry approximately $9 billion over the first five years of implementation, with the largest cost components being encryption deployment, MFA implementation, and backup-infrastructure upgrades. Small healthcare providers — practices with fewer than 50 employees — face proportionally higher compliance burdens and may need to use managed security service providers to meet the new requirements affordably.

Industry reaction has been mixed. Large health systems and hospital networks that have already invested in modern security infrastructure welcome the rule as leveling the playing field and raising the security baseline for the sector. Smaller providers and rural healthcare organizations express concern about the cost and complexity of compliance, particularly the universal encryption and MFA requirements. Business-associate organizations — cloud providers, clearinghouses, and health IT vendors — face cascading compliance obligations that may reshape the healthcare IT vendor environment.

Recommended actions for healthcare organizations

Conduct an immediate gap assessment comparing current security controls against the proposed rule's requirements. Prioritize encryption coverage, MFA deployment scope, and backup-infrastructure resilience as the areas most likely to require significant investment.

Submit comments during the 60-day public comment period, particularly on implementation timelines and legacy-device exemptions. Organizational input can influence the final rule's requirements, especially in areas where the proposed timelines are impractical for specific healthcare settings.

Begin procurement planning for MFA solutions and encryption infrastructure. The 24-month compliance timeline is aggressive given the procurement, deployment, and testing cycles typical of healthcare IT environments. Organizations that begin procurement processes now will be better positioned to meet the deadline.

Review business-associate agreements to assess the cascading compliance obligations created by the proposed rule. Ensure that BAAs include provisions for the new encryption, MFA, and recovery-time requirements, and engage key business associates early to assess their compliance readiness.

Analysis and forecast

The proposed HIPAA Security Rule modernization is the most significant healthcare cybersecurity regulatory development in over a decade. It reflects a regulatory judgment that the healthcare sector's security posture — shaped by years of flexible, risk-based compliance that permitted significant variation in actual security practices — is no longer adequate for the threat environment. The shift from addressable to mandatory requirements sends a clear message: basic security controls are no longer optional.

The rule's effectiveness will depend on enforcement. HHS's Office for Civil Rights has historically been resource-constrained, and the expanded compliance baseline will increase the volume of potential enforcement targets. Whether OCR receives sufficient resources to enforce the new requirements meaningfully will determine whether the rule drives genuine security improvement or becomes another paper-compliance exercise.

For healthcare CISOs, the proposed rule provides long-sought regulatory backing for security investments that organizational leadership has previously deprioritized. The mandatory nature of the requirements transforms security budget requests from discretionary spending proposals into regulatory compliance obligations — a reframing that can unlock resources that were previously unavailable.

PCI DSS 4.0.1 is a maintenance release that corrects errata, clarifies ambiguous requirement language, and updates guidance in the PCI DSS standard document. It does not change the compliance deadline — all organizations processing, storing, or transmitting cardholder data must be fully compliant with PCI DSS 4.0 requirements, including the future-dated requirements that became mandatory on March 31, 2025. The practical importance of 4.0.1 lies in the clarifications, which resolve interpretive disagreements that have caused assessment inconsistencies across QSAs and organizations over the past year. this analysis examines the most significant clarifications and their impact on compliance programs.

Targeted risk analysis clarifications

PCI DSS 4.0 introduced the concept of targeted risk analysis (TRA) to support its flexible-implementation philosophy. Several requirements allow organizations to determine control parameters — such as the frequency of log reviews or the periodicity of vulnerability scans — through a documented risk analysis rather than prescribing fixed intervals. The intention was to give organizations the flexibility to calibrate controls to their specific risk profile rather than imposing one-size-fits-all frequencies.

In practice, the TRA concept generated significant confusion. Organizations struggled with the documentation expectations: what constitutes an adequate risk analysis, how granular the analysis must be for each applicable requirement, and whether a single enterprise-wide risk assessment can satisfy multiple TRA obligations. QSAs interpreted the requirements differently, leading to inconsistent assessment outcomes where the same control configuration was accepted by one assessor and rejected by another.

Version 4.0.1 clarifies that each targeted risk analysis must be specific to the requirement it supports and must document the threat environment, asset criticality, control effectiveness, and residual risk for the particular control parameter being determined. A generic enterprise risk assessment does not satisfy the TRA requirement — the analysis must directly address the specific control question, such as why quarterly rather than monthly log reviews are appropriate for a particular system category. The clarification also specifies that TRAs must be reviewed and updated at least annually and whenever significant changes occur in the environment.

The practical impact is significant for organizations that took a broad-brush approach to TRA documentation. Compliance teams should review every requirement where a TRA was used to justify a non-default control parameter and ensure that the supporting analysis meets the specificity standard defined in 4.0.1. QSA firms have begun updating their assessment procedures to reflect the clarified expectations, and organizations should expect more rigorous scrutiny of TRA documentation in upcoming assessments.

Client-side script integrity requirements

Requirement 6.4.3 of PCI DSS 4.0 mandates that payment pages loading scripts in consumer browsers implement controls to ensure script integrity and authorization. This requirement was designed to address the growing threat of Magecart-style attacks, where malicious JavaScript injected into payment pages skims cardholder data during the checkout process. The requirement was future-dated and became mandatory on March 31, 2025.

The original requirement language left several implementation questions unanswered. Organizations debated whether the requirement applies only to scripts that directly handle cardholder data or to all scripts loaded on pages where payment fields are present. The scope question is materially important because modern e-commerce pages often load dozens of third-party scripts for analytics, advertising, chatbots, and other functions that do not interact with payment data but share the same page context.

Version 4.0.1 clarifies that the requirement applies to all scripts loaded and executed on payment pages, regardless of whether the scripts directly process cardholder data. The rationale is that any script executing in the same browser context as payment fields has the technical capability to access that data, and therefore must be authorized and integrity-verified. The clarification explicitly states that organizations must maintain an inventory of all scripts loaded on payment pages, document the business justification for each script, and implement integrity-verification mechanisms such as Subresource Integrity (SRI) hashes or Content Security Policy (CSP) directives.

This clarification has significant operational implications. Organizations must audit every script loaded on their payment pages, including scripts injected by tag managers, advertising platforms, and analytics providers. Scripts that cannot be integrity-verified — for example, dynamically generated scripts served from third-party domains without stable hashes — must be evaluated for removal or isolation. Payment page architectures that rely on iframes to isolate the payment form from the broader page context are explicitly recognized as a valid approach to limiting script exposure.

Customized approach validation updates

PCI DSS 4.0 introduced the customized approach as an alternative to the defined approach for meeting security objectives. Under the customized approach, organizations can implement controls that differ from the prescriptive requirements of the defined approach, provided they can demonstrate through evidence that their alternative controls meet the stated security objective with equivalent or greater effectiveness. The customized approach was designed for mature organizations with sophisticated security programs that may achieve better outcomes through tailored controls than through rigid adherence to prescriptive requirements.

Early experience with customized-approach assessments revealed challenges in validation methodology. QSAs reported difficulty establishing consistent evidence standards for demonstrating that a customized control meets a security objective equivalently. The lack of standardized testing procedures for customized implementations created assessment-quality concerns, and some organizations reported that QSAs were reluctant to accept customized approaches due to the professional liability risk associated with validating non-standard implementations.

Version 4.0.1 provides additional guidance on the evidence expectations for customized-approach validation. The updated text specifies that organizations must document the security objective being addressed, the alternative control implemented, the testing methodology used to validate effectiveness, and the results of testing. The QSA must independently verify the testing methodology and results rather than relying solely on the organization's self-assessment. The clarification also establishes that customized-approach controls must be subject to ongoing monitoring and periodic reassessment, not just one-time validation at the point of implementation.

The practical effect is to raise the bar for customized-approach adoption. Organizations considering the customized approach should invest in robust documentation and testing frameworks before engaging their QSA. The upfront effort is substantial, but the long-term flexibility to implement controls tailored to their specific environment can deliver both better security outcomes and more efficient compliance programs.

Multi-factor authentication scope adjustments

Requirement 8.4.2 of PCI DSS 4.0 mandates multi-factor authentication (MFA) for all access to the cardholder data environment (CDE), expanding the scope from the previous version's requirement that applied only to remote access and administrative access. The expansion was one of the most operationally impactful changes in PCI DSS 4.0 and generated questions about applicability to service accounts, batch processes, and API-to-API connections.

Version 4.0.1 clarifies that MFA requirements apply to interactive human authentication sessions and do not extend to non-interactive system-to-system communications. Service accounts, batch-processing credentials, and API keys used for automated data flows are not subject to MFA requirements, provided they are managed under compensating controls including credential rotation, least-privilege access, and monitoring for anomalous usage. The clarification resolves a practical impossibility — applying MFA to automated processes that have no human user to complete a second authentication factor — while maintaining the security intent of the requirement.

The clarification also confirms that MFA implementation must use at least two of the three standard authentication factor categories: something the user knows, something the user has, and something the user is. Time-based one-time passwords (TOTP), hardware security keys, push notifications, and biometric authentication all satisfy the requirement when combined with a knowledge factor. SMS-based OTP remains an acceptable but discouraged method due to known weaknesses in the telephony infrastructure.

Assessment timeline and transition considerations

Organizations currently undergoing PCI DSS assessments should coordinate with their QSA to determine when 4.0.1 will be adopted as the assessment reference. The PCI SSC has set a transition period during which assessments may reference either 4.0 or 4.0.1, but QSAs are expected to apply the 4.0.1 clarifications regardless of which version is formally cited. The practical effect is that 4.0.1's interpretive guidance is immediately applicable even before formal adoption by all assessment firms.

Self-assessment questionnaire (SAQ) templates are being updated to reflect 4.0.1 clarifications. Organizations that complete SAQs should download the updated versions when available to ensure their self-assessments align with current expectations. Merchants completing SAQ A, which applies to organizations that fully outsource payment processing, should verify that their payment-page script inventory requirements are addressed by their service provider's implementation.

Report on Compliance (ROC) templates will be updated in the first quarter of 2026. QSAs should begin familiarizing themselves with the updated evidence requirements, particularly for TRA documentation and customized-approach validation. Organizations planning assessment engagements for 2026 should build the clarified documentation expectations into their preparation timeline.

Recommended actions for compliance teams

Review every targeted risk analysis used to justify non-default control parameters in your current PCI DSS compliance program. Ensure each TRA is specific to its requirement, documents the relevant threat environment and asset context, and includes a clear rationale for the chosen control parameter. Update TRA documentation to meet the specificity standards clarified in 4.0.1.

Conduct a thorough audit of all scripts loaded on payment pages. Maintain an authorized inventory with business justifications and implement integrity-verification mechanisms for each script. Evaluate whether payment-page architecture changes — such as iframe isolation — can simplify compliance with Requirement 6.4.3.

If using or planning to use the customized approach, invest in documentation and testing frameworks that meet the updated validation expectations. Engage your QSA early to align on evidence requirements before the formal assessment.

Update MFA implementation plans to reflect the clarified scope for system-to-system communications. Ensure that service accounts and automated processes excluded from MFA are governed by appropriate compensating controls and monitoring.

Analysis and forecast

PCI DSS 4.0.1 is a necessary course correction that addresses real-world implementation challenges exposed during the first year of 4.0 enforcement. The clarifications do not change the standard's security objectives but materially affect how compliance is assessed and documented. Organizations that actively align their programs with the clarified expectations will experience smoother assessments and fewer findings.

The broader lesson is that complex compliance frameworks inevitably require iterative refinement as they encounter the diversity of real-world implementations. The PCI SSC's willingness to issue clarifications based on field experience is a governance strength that benefits the entire payment ecosystem. Organizations should stay engaged with PCI SSC communications and QSA community updates to anticipate further guidance as 4.0 implementation matures across the industry.

The European Union's Digital Operational Resilience Act (DORA) entered active enforcement in January 2026, one year after its January 17, 2025 effective date. Financial sector regulators across EU member states are now conducting operational resilience audits, reviewing Register of Information submissions, and imposing penalties for non-compliance. Financial entities and their ICT service providers face substantial fines—up to 2% of global annual turnover for financial institutions and €5 million for critical ICT providers. Organizations must demonstrate mature, continuously monitored digital resilience programs with thorough third-party risk management documentation.

DORA enforcement framework

DORA establishes harmonized requirements for ICT risk management, incident reporting, resilience testing, and third-party risk oversight across the EU financial sector. The regulation applies to a broad range of financial entities including banks, insurance companies, investment firms, payment institutions, and crypto-asset service providers. Critical ICT third-party providers serving multiple financial entities also fall under direct regulatory oversight.

National competent authorities (NCAs) in each member state hold primary enforcement responsibility for financial entities under their supervision. The three European Supervisory Authorities—EBA, EIOPA, and ESMA—coordinate cross-border enforcement and directly supervise designated critical ICT third-party service providers. This dual-level structure creates consistent enforcement while addressing sector-specific considerations.

The enforcement posture has shifted from advisory guidance to active compliance verification. Regulators are conducting on-site inspections, reviewing submitted documentation, and assessing the maturity of organizations' digital resilience programs. Organizations that treated DORA compliance as a documentation exercise rather than operational transformation face heightened scrutiny.

Enforcement priority areas include the completeness and accuracy of Register of Information submissions, the effectiveness of ICT risk management frameworks, and the robustness of third-party oversight programs. Regulators expect evidence of active risk management rather than static policy documents. Continuous monitoring, regular testing, and documented improvement cycles demonstrate compliance maturity.

ICT risk management requirements

DORA requires financial entities to establish thorough ICT risk management frameworks covering the identification, protection, detection, response, and recovery functions. The framework must be proportionate to the entity's size, complexity, and risk profile. Documented governance structures must assign clear accountability for ICT risk at management body level.

Risk identification processes must maintain current inventories of ICT assets, dependencies, and vulnerabilities. Network and system diagrams, data flow mappings, and criticality assessments provide the foundation for risk-based controls. Regular updates ensure these inventories reflect the actual technology environment.

Protection measures must address identified risks through appropriate technical and organizational controls. Access management, encryption, network segmentation, and change management represent core control categories. Controls must be documented, tested, and monitored for effectiveness.

Detection capabilities require continuous monitoring of ICT systems for anomalies and potential incidents. Security information and event management systems, intrusion detection capabilities, and log analysis support detection requirements. Detection thresholds and alerting mechanisms must be calibrated to the entity's risk profile.

Incident reporting obligations

DORA establishes strict timelines for reporting major ICT-related incidents to supervisory authorities. Initial notification must occur within four hours of incident classification. Intermediate reports providing additional details are required within 72 hours. Final reports with root cause analysis and remediation actions must be submitted within one month.

Incident classification criteria determine whether an event qualifies as major and triggers reporting obligations. Criteria include duration, geographic spread, number of affected clients, data losses, economic impact, and criticality of affected services. Organizations must implement classification procedures enabling rapid determination of reporting obligations.

Reporting templates and submission channels are specified by supervisory authorities. Organizations should familiarize themselves with their NCAs' reporting requirements and establish technical capabilities for timely submission. Delayed or incomplete incident reports can result in enforcement action independent of the underlying incident.

Voluntary notification provisions encourage reporting of significant cyber threats even before incidents materialize. Threat intelligence sharing improves collective resilience across the financial sector. Regulators consider voluntary participation in threat sharing when assessing organizational compliance culture.

Digital operational resilience testing

DORA requires regular testing of digital operational resilience through various methodologies. All covered entities must conduct basic testing including vulnerability assessments, network security testing, and scenario-based testing. Testing frequency and scope must be proportionate to ICT risk profiles.

Threat-led penetration testing (TLPT) applies to significant financial entities identified by supervisory authorities. TLPT requires sophisticated red team exercises simulating advanced threat actor techniques. Testing must be conducted by qualified internal or external testers following established frameworks such as TIBER-EU.

TLPT cycles occur at least every three years, though significant changes to ICT infrastructure or threat environment may trigger earlier testing requirements. Testing scopes must cover critical and important functions identified through business impact analysis. Results and remediation plans require supervisory reporting.

Testing programs must drive actual security improvements rather than serving as compliance checkboxes. Regulators expect evidence that testing findings result in remediation actions and that lessons learned are incorporated into ongoing risk management. Gap analysis between testing results and control improvements demonstrates program maturity.

Third-party risk management

DORA significantly expands third-party risk management obligations for financial entities. Organizations must maintain thorough registers of all ICT third-party arrangements, including subcontracting chains. Due diligence assessments, ongoing monitoring, and exit planning are required for all material ICT relationships.

The Register of Information (ROI) requires detailed documentation of ICT third-party relationships. Required information includes service descriptions, risk assessments, contractual terms, subcontractor arrangements, and evidence of ongoing oversight. Annual ROI submissions to supervisory authorities began in January 2026.

Contract requirements specify minimum provisions that must be included in agreements with ICT service providers. Service level agreements, audit rights, security requirements, incident notification obligations, and exit/termination provisions must be documented. Existing contracts require review and amendment to meet DORA standards.

A two-year transitional period for reviewing existing arrangements was granted, but enforcement expectations are increasing. New contracts and renewals must fully comply with DORA requirements immediately. Organizations should prioritize contract remediation for their most critical third-party relationships.

Penalty framework

DORA establishes significant penalty authority for supervisory regulators. Financial entities face administrative penalties up to 2% of total annual worldwide turnover for serious infringements. Individual managers may face personal liability for compliance failures within their areas of responsibility.

Critical ICT third-party service providers under direct ESA supervision face fines up to €5 million or 1% of daily worldwide turnover. Periodic penalty payments can accrue for ongoing non-compliance. In extreme cases, regulators can require financial entities to suspend or terminate arrangements with non-compliant providers.

Penalty calculations consider factors including the seriousness and duration of infringements, degree of responsibility, financial strength of the entity, profits gained or losses avoided, and cooperation with authorities. Systematic failures or repeated violations result in enhanced penalties.

Beyond financial penalties, regulators can impose operational restrictions, require specific remediation actions, or issue public statements identifying non-compliant entities. Reputational consequences of public enforcement actions may exceed direct financial penalties for many organizations.

Actions for the next two months

• Complete and validate Register of Information submissions for all ICT third-party arrangements.
• Assess ICT risk management framework maturity against DORA requirements.
• Review incident classification and reporting procedures for DORA compliance.
• Evaluate digital resilience testing programs against proportionality requirements.
• Prioritize contract remediation for critical ICT service provider relationships.
• Brief management bodies on DORA compliance status and enforcement risk.
• Document governance structures and accountability assignments for ICT risk.
• Establish ongoing compliance monitoring to demonstrate continuous improvement.

Analysis summary

DORA enforcement in January 2026 marks a significant shift from compliance preparation to active regulatory oversight. Financial entities must demonstrate operational resilience programs that are mature, documented, and continuously monitored. The focus has shifted from policy development to evidence of effective risk management practices.

Third-party risk management receives particular scrutiny given the financial sector's dependence on ICT service providers. The Register of Information requirements create unprecedented transparency into third-party relationships. Organizations with complex ICT supply chains face significant documentation and ongoing monitoring obligations.

The penalty framework provides substantial enforcement incentive. Fines up to 2% of global turnover create material financial exposure for non-compliance. Personal liability provisions ensure that individual managers cannot treat compliance as solely an organizational responsibility.

This analysis recommends that financial entities and their ICT providers prioritize DORA compliance verification against active enforcement expectations. Static documentation is insufficient; regulators expect evidence of operational resilience practices that are integrated into daily operations and continuously improved through testing and monitoring cycles.

Three new state thorough privacy laws took effect on January 1, 2026: the Indiana Consumer Data Protection Act (ICDPA), Kentucky Consumer Data Protection Act (KCDPA), and Rhode Island Data Transparency and Privacy Protection Act (RIDPA). These laws expand the state privacy patchwork to 19 states with thorough data protection requirements. Rhode Island's law introduces unique obligations including mandatory public disclosure of third parties receiving personal data and no cure period for violations. Organizations operating nationally must assess applicability across all three jurisdictions and implement appropriate compliance measures.

Indiana Consumer Data Protection Act scope

The Indiana Consumer Data Protection Act applies to entities controlling or processing personal data of 100,000 or more Indiana residents, or entities processing data of 25,000 or more residents while deriving over 50% of gross revenue from selling personal data. These thresholds align with several other state privacy laws, creating some consistency for multi-state compliance.

Indiana residents gain standard thorough privacy rights under the ICDPA: the right to confirm whether a controller processes their data, access their personal data, correct inaccuracies, delete personal data, and obtain a portable copy. Additionally, residents can opt out of processing for targeted advertising, sale of personal data, and profiling in furtherance of automated decisions producing legal or similarly significant effects.

Controllers must provide reasonably accessible privacy notices describing categories of personal data processed, purposes of processing, how consumers can exercise their rights, and categories of third parties with whom data is shared. Data protection impact assessments are required for processing activities presenting heightened risk of harm, including targeted advertising, sale of personal data, processing for profiling, and processing sensitive data.

The Indiana Attorney General has exclusive enforcement authority with no private right of action. Controllers receive a 30-day cure period to address violations before the Attorney General can pursue enforcement action. This cure period provides organizations opportunity to remediate compliance gaps before facing penalties.

Kentucky Consumer Data Protection Act requirements

Kentucky's Consumer Data Protection Act mirrors Indiana's applicability thresholds: 100,000 Kentucky residents or 25,000 residents combined with 50% or more revenue from personal data sales. The similar threshold structure simplifies compliance analysis for organizations already assessing Indiana applicability.

Consumer rights under KCDPA parallel other thorough state laws: access, correction, deletion, data portability, and opt-out rights for targeted advertising, data sales, and profiling. Kentucky provides a 30-day response window for consumer rights requests, consistent with most state privacy laws.

Kentucky offers several business-friendly exemptions distinguishing it from more stringent state laws. The law exempts data subject to sector-specific federal regulations including HIPAA, GLBA, and FERPA. Employment data and business-to-business contact information receive exemptions, reducing compliance burden for organizations processing these data categories.

Notably, Kentucky does not currently require recognition of universal opt-out mechanisms such as Global Privacy Control. This distinction means organizations cannot rely solely on browser-based opt-out signals for Kentucky compliance and must provide separate opt-out methods. Future amendments may align Kentucky with the growing number of states requiring universal opt-out recognition.

Rhode Island unique requirements

Rhode Island's Data Transparency and Privacy Protection Act establishes notably lower applicability thresholds than most state privacy laws. The law applies to entities processing data of 35,000 Rhode Island residents, or 10,000 residents combined with deriving over 20% of gross revenue from personal data sales. These lower thresholds bring smaller organizations into scope compared to other states.

Rhode Island uniquely requires public disclosure of third parties to whom personal data is sold or shared. Controllers must publicly identify the specific third parties receiving personal information, not merely categories of recipients. This transparency requirement exceeds other state laws and creates additional compliance complexity for organizations with complex data sharing arrangements.

The law imposes strict privacy notice requirements for any commercial website targeting Rhode Island residents. Privacy notices must identify categories of personal data processed, purposes of processing, categories of data sold, third parties receiving data, and an active email address for consumer inquiries. The notice must be conspicuously displayed and easily accessible.

Critically, Rhode Island provides no cure period for violations. The Attorney General can immediately pursue enforcement action without providing opportunity for remediation. This approach differs from most state privacy laws and creates heightened compliance urgency for organizations within scope. early compliance is essential given the absence of cure opportunity.

Consumer rights comparison

All three laws provide similar core consumer rights, though implementation details vary. Access rights allow consumers to confirm processing and obtain copies of their data. Correction rights enable consumers to fix inaccuracies in their personal data. Deletion rights allow consumers to request removal of their personal data subject to certain exemptions.

Data portability rights vary in scope across the three laws. Indiana and Kentucky require provision of personal data in readily usable formats. Rhode Island's portability requirements align with this approach but emphasize interoperability with the consumer's chosen services.

Opt-out rights are consistent across all three states for targeted advertising, sale of personal data, and profiling. However, the definition of "sale" varies, affecting which data transfers trigger opt-out requirements. Organizations must carefully analyze their data sharing practices against each state's sale definition.

Appeal rights require controllers to establish processes for consumers to appeal denied rights requests. All three states require appeals mechanisms, though the procedural requirements differ. Organizations should implement consistent appeal processes that satisfy the most stringent state requirements.

Enforcement mechanisms

All three states vest enforcement authority exclusively in the Attorney General with no private right of action. This enforcement model limits litigation exposure compared to states like California that permit private claims for certain violations. However, Attorney General enforcement can result in significant penalties and injunctive relief.

Indiana and Kentucky provide 30-day cure periods before enforcement actions can proceed. This cure period provides organizations with opportunity to address compliance gaps when violations are identified. Documented remediation efforts during the cure period can mitigate enforcement risk.

Rhode Island's absence of a cure period creates different enforcement dynamics. Organizations must maintain early compliance since no opportunity exists to remediate once violations are identified. This approach incentivizes preventive compliance investment rather than reactive correction.

Penalty structures vary but can include substantial civil penalties for non-compliance. Repeat violations and willful disregard for requirements can result in enhanced penalties. Organizations should assess enforcement risk based on their data processing activities and compliance posture in each state.

Multi-state compliance strategies

Organizations subject to multiple state privacy laws should consider harmonized compliance approaches. Building privacy programs to satisfy the most stringent requirements across applicable states reduces operational complexity while ensuring broad compliance. This approach often means implementing Rhode Island's transparency requirements and early compliance posture universally.

Privacy notice consolidation can simplify disclosure obligations. A single thorough privacy notice addressing all applicable state requirements is generally preferable to state-specific notices. The notice should clearly identify all categories of information required by each applicable law.

Consumer rights request handling should use unified workflows. While response timeframes and specific requirements vary, centralized request intake and processing improves consistency and reduces error risk. Automated systems can apply state-specific logic while maintaining unified underlying processes.

Data inventory and mapping efforts should encompass all states where organizations may be subject to privacy law requirements. Understanding what personal data is collected, processed, shared, and sold enables accurate applicability assessments and appropriate compliance measures across jurisdictions.

60-day priority list

• Assess applicability of Indiana, Kentucky, and Rhode Island privacy laws based on processing thresholds.
• Review and update privacy notices to address Rhode Island's specific disclosure requirements.
• Implement third-party disclosure mechanisms required by Rhode Island.
• Evaluate existing consumer rights request processes against all three states' requirements.
• Update data protection impact assessment practices to cover required processing activities.
• Assess cure period implications and adjust compliance monitoring accordingly.
• Brief legal counsel on multi-state compliance obligations and risk assessment.
• Document compliance measures to demonstrate good faith efforts if enforcement occurs.

Bottom line

The January 2026 effective dates for Indiana, Kentucky, and Rhode Island privacy laws continue the expansion of state thorough privacy requirements. Organizations must assess applicability based on varying thresholds across states and implement appropriate compliance measures. Rhode Island's unique requirements for public third-party disclosure and absence of cure period warrant particular attention.

Multi-state compliance complexity continues to grow as more states enact thorough privacy laws. Organizations should consider building privacy programs to the highest common denominator, satisfying the most stringent requirements across applicable jurisdictions. This approach reduces operational complexity while ensuring broad compliance.

Rhode Island's lower applicability thresholds and stricter enforcement approach may influence future state privacy legislation. Organizations should monitor legislative developments for similar trends in other states. early compliance investment now positions organizations well for continued regulatory expansion.

This analysis recommends that organizations conduct prompt applicability assessments for all three new laws and implement compliance measures appropriate to their data processing activities. The absence of a private right of action reduces litigation exposure, but Attorney General enforcement remains a meaningful compliance driver requiring ongoing attention.