+Articolo 97 Autenticazione
---+Articolo 97 1.
---+Articolo 97 2.
---+Articolo 97 3.
---+Articolo 97 4.
---+Articolo 97 5.

Articolo 97 Autenticazione

-

1. Panoramica

,
Articolo 97 1.

Gli Stati membri provvedono a che un prestatore di servizi di pagamento applichi l’autenticazione forte del cliente quando il pagatore:

a) 

accede al suo conto di pagamento on line;

b) 

dispone un’operazione di pagamento elettronico;

c) 

effettua qualsiasi azione, tramite un canale a distanza, che può comportare un rischio di frode nei pagamenti o altri abusi.
Articolo 97 2.
Nel caso dell’avvio di un’operazione di pagamento elettronico a distanza i cui al paragrafo 1, lettera b), gli Stati membri provvedono affinché, per le operazioni di pagamento elettronico a distanza, i prestatori di servizi di pagamento applichino l’autenticazione forte del cliente che comprenda elementi che colleghino in maniera dinamica l’operazione a uno specifico importo e a un beneficiario specifico.
Articolo 97 3.
Quanto al paragrafo 1, gli Stati membri provvedono a che i prestatori di servizi di pagamento abbiano predisposto misure di sicurezza adeguate per tutelare la riservatezza e l’integrità delle credenziali di sicurezza personalizzate degli utenti di servizi di pagamento.
Articolo 97 4.
I paragrafi 2 e 3 si applicano anche allorché i pagamenti sono disposti mediante un prestatore di servizi di disposizione di ordine di pagamento. I paragrafi 1 e 3 si applicano anche allorché le informazioni sono richieste mediante un prestatore di servizi di informazione sui conti.
Articolo 97 5.
Gli Stati membri provvedono a che il prestatore di servizi di pagamento di radicamento del conto consenta al prestatore di servizi di disposizione di ordine di pagamento e al prestatore di servizi di informazione sui conti di fare ricorso alle procedure di autenticazione fornite dal prestatore di servizi di pagamento di radicamento del conto all’utente di servizi di pagamento conformemente ai paragrafi da 1 e 3 e, qualora sia coinvolto il prestatore di servizi di disposizione di ordine di pagamento, anche conformemente al paragrafi 1, 2 e 3.

1.1 Riferimenti

1.2 Requisiti identificati

1.3 Standard correlati

2. Requisiti identificati

Requisiti

3. Standard correlati

Standard
SCF Security, Compliance & Resilience Program (SCRP)

Description

Mechanisms exist to facilitate the design, implementation, and monitoring of security, compliance and resilience governance controls.

Possible Solutions & Considerations

Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2

∙ ComplianceForge - Cybersecurity & Data Protection Program (CDPP) (https://complianceforge.com)
∙ SCFConnect (https://scfconnect.com)
∙ NIST Cybersecurity Framework (CSF) 2.0 (https://www.nist.gov/cyberframework)

Small Business (10-49 staff) / BLS Firm Size Classes 3-4

∙ ComplianceForge - Cybersecurity & Data Protection Program (CDPP) (https://complianceforge.com)
∙ SCFConnect (https://scfconnect.com)
∙ NIST Cybersecurity Framework (CSF) 2.0 (https://www.nist.gov/cyberframework)

Medium Business (50-249 staff) / BLS Firm Size Classes 5-6

∙ Steering committee
∙ ComplianceForge - Security, Compliance & Resilience Program (SCRP) (https://complianceforge.com)
∙ ComplianceForge - Cybersecurity & Data Protection Program (CDPP) (https://complianceforge.com)
∙ GRC platform (e.g., OneTrust, ServiceNow GRC, LogicGate)
∙ Secure Controls Framework (SCF), NIST SP 800-53 Rev 5 and/or ISO 27001:2022 alignment

Large Business (250-999 staff) / BLS Firm Size Classes 7-8

∙ Steering committee
∙ ComplianceForge - Security, Compliance & Resilience Program (SCRP) (https://complianceforge.com)
∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)
∙ Secure Controls Framework (SCF), NIST SP 800-53 Rev 5 and/or ISO 27001:2022 alignment

Enterprise (> 1,000 staff) / BLS Firm Size Class 9

∙ Steering committee
∙ ComplianceForge - Security, Compliance & Resilience Program (SCRP) (https://complianceforge.com)
∙ Enterprise GRC platform (e.g., Cyturus, Archer, MetricStream, ServiceNow IRM)
∙ Secure Controls Framework (SCF), NIST SP 800-53 Rev 5 and/or ISO 27001:2022 alignment

SCR-CMM

Level 0 Not Performed

Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed.

Level 1 Performed Informally

Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.
▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.
▪ Basic procedures are established for important tasks, but are ad hoc and not formally documented.
▪ The responsibility for developing and operating cybersecurity and data privacy procedures are up to the business process owner(s) to determine, including the definition and enforcement of roles and responsibilities.
▪ Governance documentation is made available to internal personnel (e.g., policies, standards and procedures).
▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.

Level 2 Planned Tracked

Cybersecurity & Data Protection Governance (GOV) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.
▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.
▪ IT and/or cybersecurity personnel ensure cybersecurity policies and standards are aligned with a leading cybersecurity framework (e.g., SCF, NIST 800-53, NIST 800-171, ISO 27002 or NIST Cybersecurity Framework).
▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement and manage the organization's internal control system.
▪ Legal representation is consulted on an as-needed basis.

Level 3 Well Defined

Cybersecurity & Data Protection Governance (GOV) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.
▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).
▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).
▪ An implemented and operational capability exists to facilitate the implementation of security, compliance and resilience governance controls.

Level 4 Quantitatively Controlled

Cybersecurity & Data Protection Governance (GOV) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.
▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).
▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).
▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.
▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).
▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.
▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.

Level 5 Continuously Improving

Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:
▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control.
▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies.
▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.
SCF Statutory, Regulatory & Contractual Compliance

Description

Mechanisms exist to facilitate the identification and implementation of relevant statutory, regulatory and contractual controls.

Possible Solutions & Considerations

Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2

∙ SCF Security, Compliance & Resilience Management System (SCRMS)
∙ Governance, Risk and Compliance (GRC) solution (e.g., SCFConnect, SureCloud, Ostendio, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)

Small Business (10-49 staff) / BLS Firm Size Classes 3-4

∙ SCF Security, Compliance & Resilience Management System (SCRMS)
∙ Governance, Risk and Compliance (GRC) solution (e.g., SCFConnect, SureCloud, Ostendio, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)

Medium Business (50-249 staff) / BLS Firm Size Classes 5-6

∙ SCF Security, Compliance & Resilience Management System (SCRMS)
∙ Governance, Risk and Compliance (GRC) solution (e.g., SCFConnect, SureCloud, Ostendio, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)
∙ Steering committee

Large Business (250-999 staff) / BLS Firm Size Classes 7-8

∙ SCF Security, Compliance & Resilience Management System (SCRMS)
∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)
∙ Steering committee

Enterprise (> 1,000 staff) / BLS Firm Size Class 9

∙ SCF Security, Compliance & Resilience Management System (SCRMS)
∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)
∙ Steering committee

SCR-CMM

Level 0 Not Performed

Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed.

Level 1 Performed Informally

Compliance (CPL) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with CPL domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Compliance management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ Compliance efforts are narrowly-limited to certain compliance requirements.
▪ IT and/or cybersecurity personnel use an informal process to govern statutory, regulatory and contractual compliance obligations.

Level 2 Planned Tracked

Compliance (CPL) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are documented and maintained by process owners.
▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CPL domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Compliance management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations.
▪ IT and/or cybersecurity perform an informal annual review of existing compliance requirements and research evolving or new requirements.

Level 3 Well Defined

Compliance (CPL) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with CPL domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Standardized Operating Procedures (SOP) associated with CPL domain capabilities are well-documented and kept current by process owners.
▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).
▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CPL domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).
▪ An implemented and operational capability exists to facilitate the identification and implementation of relevant statutory, regulatory and contractual controls.

Level 4 Quantitatively Controlled

Utilize SCR-CMM Level 3 criteria definitions:
▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control.
▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.

Level 5 Continuously Improving

Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:
▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control.
▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies.
▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.
SCF Strong Customer Authentication (SCA)

Description

Mechanisms exist to implement Strong Customer Authentication (SCA) for consumers to reasonably prove their identity.

Possible Solutions & Considerations

Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2

∙ Use MFA for customer-facing authentication

Small Business (10-49 staff) / BLS Firm Size Classes 3-4

∙ Strong customer authentication (SCA) policy
∙ MFA for customer accounts

Medium Business (50-249 staff) / BLS Firm Size Classes 5-6

∙ Formal SCA implementation for applicable customer services

Large Business (250-999 staff) / BLS Firm Size Classes 7-8

∙ Enterprise SCA program for customer-facing services
∙ PSD2 compliance where applicable

Enterprise (> 1,000 staff) / BLS Firm Size Class 9

∙ Enterprise customer authentication platform (e.g., Auth0, Okta Customer Identity)
∙ SCA enforcement
∙ PSD2/FIDO2 compliance

SCR-CMM

Level 0 Not Performed

Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed.

Level 1 Performed Informally

SCR-CMM Level 1 criteria definitions are not available for this control:
▪ A reasonable person would conclude this control requires a structured process.
▪ At this level of maturity, the "ad hoc" nature of performing a capability informally would indicate the intent of the control is not met due to a lack of consistency and formality.

Level 2 Planned Tracked

Web Security (WEB) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are documented and maintained by process owners.
▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with WEB domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Web security-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Web security management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.

Level 3 Well Defined

Web Security (WEB) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with WEB domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Standardized Operating Procedures (SOP) associated with WEB domain capabilities are well-documented and kept current by process owners.
▪ A web management team, or simiE210:E1635main capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of web management operations (e.g., secure web gateway and Content Management System (CMS) solution).
▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with WEB domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).
▪ An implemented and operational capability exists to implement Strong Customer Authentication (SCA) for consumers to reasonably prove their identity.

Level 4 Quantitatively Controlled

Web Security (WEB) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.
▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).
▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).
▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.
▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).
▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.
▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.

Level 5 Continuously Improving

Web Security (WEB) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.
▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.
▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies.