Matriz de responsabilidad del cliente de PCI DSS

1.3.3 Los NSC se instalan entre todas las redes inalámbricas y el CDE, independientemente de si la red inalámbrica es un CDE, de tal forma que:

• Todo el tráfico inalámbrico procedente de redes inalámbricas hacia el CDE se deniega por defecto.
• En el CDE sólo se permite el tráfico inalámbrico con fines comerciales autorizados.

1.4.2 El tráfico entrante de redes no confiables a redes confiables está restringido a:

• Comunicaciones con componentes del sistema autorizados a proporcionar servicios, protocolos y puertos de acceso público.
• Respuestas con estado a comunicaciones iniciadas por componentes del sistema en una red de confianza.
• El resto del tráfico es denegado.

1.5.1 Los controles de seguridad se implementan en todos los dispositivos informáticos, incluidos los dispositivos propiedad de la empresa y de los empleados, que se conectan tanto a redes no fiables (incluida Internet) como al CDE de la siguiente manera:

• Se definen parámetros de configuración específicos para evitar que se introduzcan amenazas en la red de la entidad.
• Los controles de seguridad funcionan activamente.
• Los controles de seguridad no pueden ser alterados por los usuarios de los dispositivos informáticos a menos que estén específicamente documentados y autorizados por la dirección caso por caso durante un periodo limitado.
  

2.2.1 Las normas de configuración se desarrollan, aplican y mantienen para:

• Cubra todos los componentes del sistema.
• Abordar todas las vulnerabilidades de seguridad conocidas.
• Ser coherente con las normas de refuerzo del sistema aceptadas por la industria o las recomendaciones de refuerzo del proveedor.
• Actualizarse a medida que se identifiquen nuevos problemas de vulnerabilidad, tal como se define en la condición 6.3.1.
• Se aplicará cuando se configuren nuevos sistemas y se verifique que están instalados antes o inmediatamente después de que un componente del sistema se conecte a un entorno de producción.

2.2.2 Las cuentas de proveedores por defecto se gestionan del siguiente modo:

• Si se va a utilizar la(s) cuenta(s) predeterminada(s) del proveedor, se cambiará la contraseña predeterminada de acuerdo con el requisito 8.3.6.
• Si la(s) cuenta(s) predeterminada(s) del proveedor no se va(n) a utilizar, la cuenta se elimina o desactiva.

2.2.3 Las funciones primarias que requieren distintos niveles de seguridad se gestionan del siguiente modo:

• Sólo existe una función primaria en un componente del sistema, O
• Las funciones primarias con diferentes niveles de seguridad que existen en el mismo componente del sistema están aisladas entre sí, O
• Las funciones primarias con diferentes niveles de seguridad en el mismo componente del sistema están todas protegidas al nivel requerido por la función con mayor necesidad de seguridad.

2.2.5 Si hay servicios, protocolos o demonios inseguros:

• La justificación empresarial está documentada.
• Se documentan e implementan características de seguridad adicionales que reducen el riesgo de utilizar servicios, protocolos o demonios inseguros.

2.3.1 Para los entornos inalámbricos conectados al CDE o que transmiten datos de cuentas, todos los valores predeterminados de los proveedores inalámbricos se cambian en la instalación o se confirma que son seguros, incluidos, entre otros:

• Claves de encriptación inalámbrica por defecto.
• Contraseñas de los puntos de acceso inalámbricos.
• SNMP por defecto.
• Cualquier otro incumplimiento del proveedor inalámbrico relacionado con la seguridad.

2.3.2 Para los entornos inalámbricos conectados al CDE o que transmiten datos de cuentas, las claves de encriptación inalámbrica se cambian de la siguiente manera:

• Siempre que el personal con conocimientos sobre la clave abandone la empresa o la función para la que eran necesarios dichos conocimientos.
• Siempre que se sospeche o se sepa que una clave está comprometida.

• Cobertura para todas las ubicaciones de datos de cuentas almacenadas.
• Cobertura para cualquier dato sensible de autenticación (DAS) almacenado antes de completar la autorización. Este punto es una práctica recomendada hasta el 31 de marzo de 2025, fecha a partir de la cual se exigirá como parte del requisito 3.2.1 y deberá tenerse plenamente en cuenta durante una evaluación de PCI DSS.
• Limitar la cantidad de datos almacenados y el tiempo de conservación a lo que exigen los requisitos legales, reglamentarios o empresariales.
• Requisitos específicos de conservación para los datos de cuentas almacenados que definan la duración del periodo de conservación e incluyan una justificación empresarial documentada. Procesos para eliminar de forma segura o hacer irrecuperables los datos de las cuentas cuando ya no se necesiten de acuerdo con la política de conservación.
• Un proceso para verificar, al menos una vez cada tres meses, que los datos de cuentas almacenados que superan el periodo de conservación definido se han eliminado de forma segura o se han hecho irrecuperables.

3.3.3 Requisito adicional para emisores y empresas que apoyan servicios de emisión y almacenan datos sensibles de autenticación: Cualquier almacenamiento de datos sensibles de autenticación es:

• Limitado a lo que se necesita para una necesidad empresarial legítima del emisor y está garantizado.
• Cifrado mediante criptografía fuerte.

3.5.1 El PAN se vuelve ilegible en cualquier lugar donde se almacene utilizando cualquiera de los siguientes métodos:

• Hashes unidireccionales basados en criptografía fuerte de todo el PAN.
• Truncamiento (el hash no se puede utilizar para reemplazar el segmento truncado de PAN).
  • Si en un entorno existen versiones hash y truncadas de la misma PAN, o diferentes formatos de truncamiento de la misma PAN, se establecen controles adicionales para que las diferentes versiones no puedan correlacionarse para reconstruir la PAN original.
• Índice de fichas. Criptografía sólida con procesos y procedimientos de gestión de claves asociados.

3.5.1.3 Si se utiliza el cifrado a nivel de disco o partición (en lugar del cifrado a nivel de archivo, columna o campo de la base de datos) para hacer ilegible PAN, se gestiona de la siguiente manera:

• El acceso lógico se gestiona por separado e independientemente de los mecanismos nativos de autenticación y control de acceso del sistema operativo.
• Las claves de descifrado no están asociadas a cuentas de usuario.
• Los factores de autenticación (contraseñas, frases de contraseña o claves criptográficas) que permiten acceder a datos no cifrados se almacenan de forma segura.

3.6.1 Se definen e implementan procedimientos para proteger las claves criptográficas utilizadas para proteger los datos de cuentas almacenados contra la divulgación y el uso indebido que incluyen:

• El acceso a las llaves está restringido al menor número de custodios necesario.
• Las claves de cifrado son al menos tan fuertes como las claves de cifrado de datos que protegen.
• Las claves de cifrado se almacenan separadas de las claves de cifrado de datos.
• Las llaves se guardan de forma segura en el menor número posible de lugares y formas.

3.6.1.1 Requisito adicional solo para proveedores de servicios: Se mantiene una descripción documentada de la arquitectura criptográfica que incluye:

• Detalles de todos los algoritmos, protocolos y claves utilizados para la protección de los datos almacenados de las cuentas, incluida la intensidad de la clave y su fecha de caducidad.
• Impedir el uso de las mismas claves criptográficas en entornos de producción y de prueba. Este punto es una práctica recomendada hasta el 31 de marzo de 2025, fecha a partir de la cual se exigirá como parte del requisito 3.6.1 y deberá tenerse plenamente en cuenta durante una evaluación de PCI DSS.
• Descripción del uso de claves para cada clave.
• Inventario de todos los módulos de seguridad de hardware (HSM), sistemas de gestión de claves (KMS) y otros dispositivos criptográficos seguros (SCD) utilizados para la gestión de claves, incluidos el tipo y la ubicación de los dispositivos, como se indica en la condición 12.3.4.

3.6.1.2 Las claves secretas y privadas utilizadas para cifrar/descifrar los datos de las cuentas almacenadas se guardan en todo momento en una (o varias) de las siguientes formas:

• Cifrado con una clave de cifrado que sea al menos tan fuerte como la clave de cifrado de datos, y que se almacene por separado de la clave de cifrado de datos.
• Dentro de un dispositivo criptográfico seguro (SCD), como un módulo de seguridad de hardware (HSM) o un dispositivo de punto de interacción aprobado por la STP.
• Como al menos dos componentes clave completos o acciones clave, de acuerdo con un método aceptado por la industria.

3.7.4 Se implementan políticas y procedimientos de gestión de claves para los cambios de claves criptográficas que han llegado al final de su criptoperíodo, según lo definido por el proveedor de la aplicación asociada o el propietario de la clave, y sobre la base de las mejores prácticas y directrices del sector, incluidas las siguientes:

• Un criptoperiodo definido para cada tipo de clave en uso.
• Proceso de cambio de claves al final del criptoperiodo definido.
  

3.7.5 Los procedimientos de las políticas de gestión de claves se aplican para incluir la retirada, sustitución o destrucción de las claves utilizadas para proteger los datos de cuentas almacenados, según se considere necesario cuando:

• La clave ha llegado al final de su criptoperiodo definido.
• La integridad de la clave se ha debilitado, incluso cuando el personal con conocimiento de un componente de la clave en texto claro abandona la empresa, o la función para la que se conocía el componente de la clave.
• Se sospecha o se sabe que la clave está comprometida.
• Las claves retiradas o sustituidas no se utilizan para las operaciones de cifrado.
  

4.2 PAN se protege con criptografía fuerte durante la transmisión.

4.2.1 Para salvaguardar PAN durante la transmisión a través de redes públicas abiertas, se aplican protocolos de seguridad y criptografía sólidos:

• Solo se aceptan claves y certificados de confianza.Los certificados utilizados para salvaguardar PAN durante la transmisión a través de redes abiertas y públicas se confirman como válidos y no están caducados ni revocados.
• El protocolo en uso sólo admite versiones o configuraciones seguras y no admite el uso de versiones, algoritmos, tamaños de clave o implementaciones inseguros.
• La fuerza del cifrado es apropiada para la metodología de cifrado en uso.

5.2.2 La(s) solución(es) antimalware desplegada(s):

• Detecta todos los tipos de malware conocidos.
• Elimina, bloquea o contiene todos los tipos conocidos de malware.

5.2.3 Los componentes del sistema que no presentan riesgo de malware se evalúan periódicamente para incluir lo siguiente:

• Una lista documentada de todos los componentes del sistema sin riesgo de malware.
• Identificación y evaluación de amenazas de malware en evolución para esos componentes del sistema.
• Confirmación de si dichos componentes del sistema siguen sin requerir protección antimalware.

5.3.2 La(s) solución(es) antimalware:

• Realiza exploraciones periódicas y exploraciones activas o en tiempo real.

o

• Realiza análisis continuos del comportamiento de sistemas o procesos.

6.2.1 Los programas informáticos a medida y personalizados se desarrollan de forma segura:

• Basado en las normas del sector y/o las mejores prácticas para un desarrollo seguro.
• De acuerdo con PCI DSS (por ejemplo, autenticación y registro seguros).
• Incorporación de la consideración de las cuestiones de seguridad de la información durante cada etapa del ciclo de vida de desarrollo del software.

6.2.2 El personal de desarrollo de software que trabaja en programas a medida y personalizados recibe formación al menos una vez cada 12 meses, como se indica a continuación:

• Sobre la seguridad de los programas informáticos relacionados con su función laboral y los lenguajes de desarrollo.
• Incluido el diseño de software seguro y las técnicas de codificación segura.
• Incluido, si se utilizan herramientas de pruebas de seguridad, cómo utilizarlas para detectar vulnerabilidades en el software.

6.2.3 El software a medida y personalizado se revisa antes de ponerlo en producción o a disposición de los clientes, para identificar y corregir posibles vulnerabilidades de codificación, como se indica a continuación:

• Las revisiones de código garantizan que el código se desarrolle de acuerdo con las pautas de codificación segura.
• Las revisiones del código buscan vulnerabilidades tanto existentes como emergentes en el software.
• Las correcciones apropiadas se implementan antes de la publicación.

6.2.3.1 Si se realizan revisiones manuales del código de los programas a medida y personalizados antes de pasarlos a producción, los cambios en el código lo son:

• Revisado por personas distintas del autor del código original, y que conozcan las técnicas de revisión de código y las prácticas de codificación segura.
• Revisado y aprobado por la dirección antes de su publicación.

6.2.4 Las técnicas de ingeniería de software u otros métodos están definidos y en uso por el personal de desarrollo de software para prevenir o mitigar los ataques de software comunes y las vulnerabilidades relacionadas en el software a medida y personalizado, incluyendo pero no limitado a lo siguiente:

• Ataques de inyección, incluidos SQL, LDAP, XPath u otros fallos de tipo comando, parámetro, objeto, fallo o inyección.
• Ataques a datos y estructuras de datos, incluidos los intentos de manipular búferes, punteros, datos de entrada o datos compartidos.
• Ataques al uso de criptografía, incluyendo intentos de explotar implementaciones criptográficas, algoritmos, suites de cifrado o modos de operación débiles, inseguros o inapropiados.
• Ataques a la lógica empresarial, incluidos los intentos de abusar o eludir las características y funcionalidades de la aplicación mediante la manipulación de API, protocolos y canales de comunicación, funcionalidades del lado del cliente u otras funciones y recursos del sistema/aplicación. Esto incluye el cross-site scripting (XSS) y el cross-site request forgery (CSRF). Ataques a los mecanismos de control de acceso, incluidos los intentos de eludir o abusar de los mecanismos de identificación, autenticación o autorización, o los intentos de aprovechar las deficiencias en la aplicación de dichos mecanismos.
• Ataques a través de cualquier vulnerabilidad de "alto riesgo" identificada en el proceso de identificación de vulnerabilidades, tal como se define en el requisito 6.3.1.

6.3.1 Las vulnerabilidades de seguridad se identifican y gestionan del siguiente modo:

• Las nuevas vulnerabilidades de seguridad se identifican utilizando fuentes de información sobre vulnerabilidades de seguridad reconocidas por el sector, incluidas las alertas de equipos de respuesta a emergencias informáticas internacionales y nacionales (Certus).
• A las vulnerabilidades se les asigna una clasificación de riesgo basada en las mejores prácticas del sector y en la consideración del impacto potencial.
• Las clasificaciones de riesgo identifican, como mínimo, todas las vulnerabilidades consideradas de alto riesgo o críticas para el entorno.
• Se cubren las vulnerabilidades del software a medida y personalizado, y del software de terceros (por ejemplo, sistemas operativos y bases de datos).

6.3.3 Todos los componentes del sistema están protegidos frente a vulnerabilidades conocidas mediante la instalación de los parches/actualizaciones de seguridad aplicables, tal y como se indica a continuación:

• Los parches/actualizaciones críticos o de alta seguridad (identificados según el proceso de clasificación de riesgos en el requisito 6.3.1) se instalan en el plazo de un mes desde su publicación.
• Todos los demás parches/actualizaciones de seguridad aplicables se instalan en un plazo adecuado determinado por la entidad (por ejemplo, en los tres meses siguientes a la publicación).
  

6.4.1 Para las aplicaciones web de cara al público, las nuevas amenazas y vulnerabilidades se abordan de forma continua y estas aplicaciones están protegidas contra los ataques conocidos de la siguiente manera:

• Revisión de las aplicaciones web de cara al público mediante herramientas o métodos manuales o automatizados de evaluación de la seguridad de las vulnerabilidades de las aplicaciones, como se indica a continuación:
  • Al menos una vez cada 12 meses y después de cambios significativos.
  • Por una entidad especializada en la seguridad de las aplicaciones.
  • Incluidos, como mínimo, todos los ataques informáticos comunes del requisito 6.2.4.
  • Todas las vulnerabilidades se clasifican de acuerdo con el requisito 6.3.1.
  • Se han corregido todas las vulnerabilidades.
  • La solicitud se vuelve a evaluar después de las correcciones

o

• Instalar una o varias soluciones técnicas automatizadas que detecten e impidan continuamente los ataques basados en la web, como se indica a continuación:
  • Se instala delante de las aplicaciones web públicas para detectar y prevenir los ataques basados en web.
  • En funcionamiento y actualizados según proceda.
  • Generación de registros de auditoría.
  • Configurado para bloquear ataques basados en web o generar una alerta que se investiga inmediatamente.

6.4.2 Para las aplicaciones web de cara al público, se despliega una solución técnica automatizada que detecta y previene continuamente los ataques basados en la web, con al menos lo siguiente:

• Se instala delante de las aplicaciones web públicas y se configura para detectar y prevenir ataques basados en web.
• En funcionamiento y actualizados según proceda.
• Generación de registros de auditoría.
• Configurado para bloquear ataques basados en web o generar una alerta que se investiga inmediatamente.

6.4.3 Todos los scripts de las páginas de pago que se cargan y ejecutan en el navegador del consumidor se gestionan de la siguiente manera:

• Se implementa un método para confirmar que cada script está autorizado.
• Se aplica un método para garantizar la integridad de cada guión.
• Se mantiene un inventario de todos los guiones con una justificación escrita de por qué cada uno es necesario.

6.5.1 Los cambios en todos los componentes del sistema en el entorno de producción se realizan de acuerdo con los procedimientos establecidos que incluyen:

• Motivo y descripción del cambio.
• Documentación sobre el impacto en la seguridad.
• Aprobación de cambios documentada por partes autorizadas.
• Pruebas para verificar que el cambio no afecta negativamente a la seguridad del sistema.
• En el caso de los cambios de software a medida y personalizados, se comprueba que todas las actualizaciones cumplen el requisito 6.2.4 antes de ponerlas en producción.
• Procedimientos para hacer frente a los fallos y volver a un estado seguro.

7.2 El acceso a los componentes y datos del sistema está debidamente definido y asignado.

7.2.1 Se define un modelo de control de acceso que incluye la concesión de acceso de la siguiente manera:

• Acceso adecuado en función de la actividad de la entidad y de sus necesidades de acceso.
• El acceso a los componentes del sistema y a los recursos de datos se basa en la clasificación profesional y las funciones de los usuarios.
• Los privilegios mínimos necesarios (por ejemplo, usuario, administrador) para realizar una función laboral.

7.2.2 El acceso se asigna a los usuarios, incluidos los privilegiados, en función de:

• Clasificación y función del puesto.
• Privilegios mínimos necesarios para desempeñar las responsabilidades del puesto.

7.2.4 Todas las cuentas de usuario y los privilegios de acceso relacionados, incluidas las cuentas de terceros/proveedores, se revisan del siguiente modo: Al menos una vez cada seis meses.

• Garantizar que las cuentas de usuario y el acceso sigan siendo apropiados en función del puesto de trabajo.
• Se aborda cualquier acceso inadecuado.
• La dirección reconoce que el acceso sigue siendo adecuado.

7.2.5 Todas las cuentas de aplicaciones y sistemas y los privilegios de acceso relacionados se asignan y gestionan de la siguiente manera:

• Basado en los mínimos privilegios necesarios para la operatividad del sistema o aplicación.
• El acceso está limitado a los sistemas, aplicaciones o procesos que requieren específicamente su uso.

7.2.5.1 Todos los accesos de las cuentas de aplicaciones y sistemas y los privilegios de acceso relacionados se revisan de la siguiente manera:

• Periódicamente (con la frecuencia definida en el análisis de riesgos específico de la entidad, que se realiza de acuerdo con todos los elementos especificados en la condición 12.3.1).
• El acceso a la aplicación/sistema sigue siendo el adecuado para la función que se realiza.
• Se aborda cualquier acceso inadecuado.
• La dirección reconoce que el acceso sigue siendo adecuado.

7.2.6 El acceso de todos los usuarios a los depósitos de consulta de datos almacenados de titulares de tarjetas está restringido de la siguiente manera:

• A través de aplicaciones u otros métodos programáticos, con acceso y acciones permitidas en función de los roles de usuario y los menores privilegios.
• Sólo el administrador o administradores responsables pueden acceder o consultar directamente los depósitos de CHD almacenados.

8.2.2 Las cuentas de grupo, compartidas o genéricas, u otras credenciales de autenticación compartidas sólo se utilizan cuando es necesario de forma excepcional, y se gestionan del siguiente modo:

• Se impide el uso de la cuenta a menos que sea necesario por una circunstancia excepcional.
• Su uso se limita al tiempo necesario para la circunstancia excepcional.
• La justificación empresarial para su uso está documentada.
• Su uso está explícitamente aprobado por la dirección. La identidad del usuario individual se confirma antes de concederle acceso a una cuenta.
• Cada acción realizada es atribuible a un usuario individual.

8.2.3 Requisito adicional solo para proveedores de servicios: Los proveedores de servicios con acceso remoto a las instalaciones de los clientes utilizan factores de autenticación únicos para cada una de ellas.

8.2.4 La adición, eliminación y modificación de identificadores de usuario, factores de autenticación y otros objetos identificadores se gestionan del siguiente modo:

• Autorizado con el visto bueno correspondiente.
• Implementado sólo con los privilegios especificados en la aprobación documentada.

8.2.7 Las cuentas utilizadas por terceros para acceder, dar soporte o mantener componentes del sistema mediante acceso remoto se gestionan del siguiente modo:

• Habilitado solo durante el período de tiempo necesario y deshabilitado cuando no está en uso.
• El uso se controla para detectar actividades inesperadas.

8.3.1 Todos los accesos de usuarios y administradores a los componentes del sistema se autentican mediante al menos uno de los siguientes factores de autenticación:

• Algo que sepa, como una contraseña o una frase de contraseña.
• Algo que tenga, como un dispositivo token o una tarjeta inteligente.
• Algo que usted es, como un elemento biométrico.

8.3.4 Los intentos de autenticación no válidos están limitados por:

• Bloqueo del identificador de usuario tras un máximo de 10 intentos.
• Fijar la duración del bloqueo en un mínimo de 30 minutos o hasta que se confirme la identidad del usuario.

8.3.5 Si se utilizan contraseñas/frases de contraseña como factores de autenticación para cumplir el requisito 8.3.1, se establecen y restablecen para cada usuario del siguiente modo:

• Establezca un valor único para el primer uso y al reiniciar.
• Obligados a cambiarse inmediatamente después del primer uso. 

8.3.6 Si se utilizan contraseñas/frases de contraseña como factores de autenticación para cumplir el requisito 8.3.1, deberán cumplir el siguiente nivel mínimo de complejidad:

• Una longitud mínima de 12 caracteres (o SI el sistema no admite 12 caracteres, una longitud mínima de ocho caracteres).
• Contienen caracteres numéricos y alfabéticos.

8.3.8 Las políticas y procedimientos de autenticación se documentan y comunican a todos los usuarios, incluidos:

• Orientación sobre la selección de factores de autenticación fuertes.
• Orientación sobre cómo deben proteger los usuarios sus factores de autenticación.
• Instrucciones para no reutilizar contraseñas/frases de contraseña utilizadas anteriormente.
• Instrucciones para cambiar las contraseñas/frases de paso si hay alguna sospecha o conocimiento de que la contraseña/frases de paso han sido comprometidas y cómo informar del incidente.

8.3.9 Si se utilizan contraseñas/frases de contraseña como único factor de autenticación para el acceso de los usuarios (es decir, en cualquier implementación de autenticación de factor único), entonces:

• Las contraseñas/frases de contraseña se cambian al menos una vez cada 90 días, O
• La postura de seguridad de las cuentas se analiza dinámicamente, y el acceso en tiempo real a los recursos se determina automáticamente en consecuencia.

8.3.10 Requisito adicional solo para proveedores de servicios:

Si se utilizan contraseñas/frases de contraseña como único factor de autenticación para el acceso de los usuarios clientes a los datos de los titulares de tarjetas (es decir, en cualquier implementación de autenticación de factor único), se proporcionará a los usuarios clientes una guía que incluya:

• Orientación para que los clientes cambien periódicamente sus contraseñas o frases de contraseña.
• Orientación sobre cuándo y en qué circunstancias deben cambiarse las contraseñas o frases de contraseña.

8.3.10.1 Requisito adicional solo para proveedores de servicios:

Si se utilizan contraseñas/frases de contraseña como único factor de autenticación para el acceso de los usuarios clientes (es decir, en cualquier implementación de autenticación de factor único), entonces:

• Las contraseñas/frases de contraseña se cambian al menos una vez cada 90 días, O
• La postura de seguridad de las cuentas se analiza dinámicamente, y el acceso en tiempo real a los recursos se determina automáticamente en consecuencia. 

8.3.11 Cuando se utilizan factores de autenticación como fichas de seguridad físicas o lógicas, tarjetas inteligentes o certificados:

• Los factores se asignan a un usuario individual y no se comparten entre varios usuarios.
• Los controles físicos y/o lógicos garantizan que sólo el usuario previsto pueda utilizar ese factor para acceder.

8.4 La autenticación multifactor (MFA) se implementa para asegurar el acceso al CDE.

8.4.1 La MFA está implantada para todos los accesos no consulares al CDE del personal con acceso administrativo.

8.4.2 La MFA está implantada para todos los accesos al CDE.

8.4.3 La AMF se aplica a todos los accesos remotos a la red procedentes de fuera de la red de la entidad que puedan acceder o afectar al CDE de la siguiente manera:

• Todos los accesos remotos de todo el personal, tanto usuarios como administradores, originados desde fuera de la red de la entidad.
• Todos los accesos remotos de terceros y proveedores.

8.5 Los sistemas de autenticación multifactor (MFA) están configurados para evitar usos indebidos.

8.5.1 Los sistemas AMF se aplican de la siguiente manera:

• El sistema MFA no es susceptible a ataques de repetición.
• Los sistemas de AMF no pueden ser eludidos por ningún usuario, incluidos los usuarios administrativos, a menos que esté específicamente documentado y autorizado por la dirección con carácter excepcional, durante un periodo de tiempo limitado.
• Se utilizan al menos dos tipos diferentes de factores de autenticación.
• Es necesario superar todos los factores de autenticación antes de conceder el acceso.

8.6 El uso de cuentas de aplicaciones y sistemas y los factores de autenticación asociados se gestionan de forma estricta.

8.6.1 Si las cuentas utilizadas por los sistemas o aplicaciones pueden utilizarse para el inicio de sesión interactivo, se gestionan del siguiente modo:

• Se impide el uso interactivo a menos que sea necesario por una circunstancia excepcional.
• El uso interactivo se limita al tiempo necesario para la circunstancia excepcional.
• La justificación empresarial del uso interactivo está documentada.
• El uso interactivo está explícitamente aprobado por la dirección.
• La identidad del usuario individual se confirma antes de concederle acceso a la cuenta.
• Cada acción realizada es atribuible a un usuario individual.

8.6.2 Las contraseñas/frases de contraseña para cualquier aplicación y cuentas de sistema que puedan utilizarse para el inicio de sesión interactivo no están codificadas en scripts, archivos de configuración/propiedades o código fuente personalizado.

8.6.3 Las contraseñas/frases de contraseña para cualquier aplicación y cuentas del sistema están protegidas contra el uso indebido de la siguiente manera:

• Las contraseñas/frases de contraseña se cambian periódicamente (con la frecuencia definida en el análisis de riesgos específico de la entidad, que se realiza de acuerdo con todos los elementos especificados en la condición 12.3.1) y ante la sospecha o confirmación de un compromiso.
• Las contraseñas/frases de contraseña se construyen con la suficiente complejidad apropiada para la frecuencia con la que la entidad cambia las contraseñas/frases de contraseña.

9.2.1.1 El acceso físico individual a las zonas sensibles del CDE se supervisa mediante cámaras de vídeo o mecanismos de control de acceso físico (o ambos), como se indica a continuación:

• Se controlan los puntos de entrada y salida de las zonas sensibles del CDE.
• Los dispositivos o mecanismos de vigilancia están protegidos contra la manipulación o la inutilización.
• Los datos recogidos se revisan y se correlacionan con otras entradas.
• Los datos recogidos se almacenan durante al menos tres meses, salvo que la ley disponga lo contrario.

9.3 Se autoriza y gestiona el acceso físico del personal y los visitantes.

9.3.1 Se implementan procedimientos para autorizar y gestionar el acceso físico del personal al CDE, incluyendo:

• Identificación del personal.
• Gestionar los cambios en los requisitos de acceso físico de una persona.
• Revocación o cese de la identificación del personal.
• Limitar el acceso al proceso o sistema de identificación al personal autorizado.

9.3.1.1 El acceso físico del personal a las zonas sensibles del CDE se controla del siguiente modo:

• El acceso se autoriza y se basa en la función individual del puesto.
• El acceso se revoca inmediatamente tras la finalización.
• Todos los mecanismos de acceso físico, como llaves, tarjetas de acceso, etc., se devuelven o desactivan en el momento del cese.

9.3.2 Se implementan procedimientos para autorizar y gestionar el acceso de visitantes al CDE, incluyendo:

• Las visitas se autorizan antes de entrar.
• Los visitantes son escoltados en todo momento.
• Los visitantes están claramente identificados y se les entrega una tarjeta u otra identificación que caduca.
• Las tarjetas de visitante u otra identificación distinguen visiblemente a los visitantes del personal.

9.3.4 Se utiliza un registro de visitantes para mantener un registro físico de la actividad de los visitantes dentro de las instalaciones y dentro de las zonas sensibles, incluyendo:

• El nombre del visitante y la organización a la que representa.
• La fecha y hora de la visita.
• Nombre del personal que autoriza el acceso físico.
• Conservar el registro durante al menos tres meses, salvo restricción legal.

9.4.3 Los soportes con datos de titulares de tarjetas enviados fuera de las instalaciones se protegen del siguiente modo:

• Se registran los medios enviados fuera de las instalaciones.
• Los soportes se envían por mensajería segura u otro método de entrega que pueda rastrearse con precisión.
• Los registros de seguimiento externos incluyen detalles sobre la ubicación de los medios.

9.4.4 La dirección aprueba todos los soportes con datos de titulares de tarjetas que se trasladan fuera de las instalaciones (incluso cuando los soportes se distribuyen a particulares).

9.4.5 Se mantienen registros de inventario de todos los soportes electrónicos con datos de titulares de tarjetas.

9.4.5.1 Los inventarios de soportes electrónicos con datos de titulares de tarjetas se realizan al menos una vez cada 12 meses.

9.4.6 Los materiales impresos con datos de titulares de tarjetas se destruyen cuando dejan de ser necesarios por motivos empresariales o legales, como se indica a continuación:

• Los materiales se trituran transversalmente, se incineran o se pulverizan para que los datos del titular de la tarjeta no puedan reconstruirse.
• Los materiales se guardan en contenedores de almacenamiento seguros antes de su destrucción.

9.4.7 Los soportes electrónicos con datos de titulares de tarjetas se destruyen cuando dejan de ser necesarios por motivos empresariales o legales mediante uno de los siguientes procedimientos:

• Se destruyen los soportes electrónicos.
• Los datos del titular de la tarjeta se vuelven irrecuperables, de modo que no pueden reconstruirse.

9.5.1 Los dispositivos POI que capturan datos de tarjetas de pago mediante la interacción física directa con el factor de forma de la tarjeta de pago están protegidos contra la manipulación y la sustitución no autorizada, incluyendo lo siguiente:

• Mantener una lista de dispositivos POI. Inspeccionar periódicamente los dispositivos de PDI en busca de manipulaciones o sustituciones no autorizadas.
• Formar al personal para que esté atento a comportamientos sospechosos y denuncie la manipulación o sustitución no autorizada de dispositivos.

9.5.1.1 Se mantiene una lista actualizada de dispositivos POI, que incluye:

• Marca y modelo del aparato.
• Ubicación del dispositivo.
• Número de serie del dispositivo u otros métodos de identificación exclusiva.

9.5.1.3 Se proporciona formación al personal de los entornos de PDI para que sean conscientes de los intentos de manipulación o sustitución de los dispositivos de PDI, e incluye:

• Verificar la identidad de cualquier tercera persona que afirme ser personal de reparación o mantenimiento, antes de concederle acceso para modificar o solucionar problemas de los dispositivos.
• Procedimientos para garantizar que los dispositivos no se instalan, sustituyen o devuelven sin verificar.
• Estar atento a comportamientos sospechosos en torno a los dispositivos.
• Informar al personal adecuado sobre comportamientos sospechosos e indicios de manipulación o sustitución de dispositivos.

10.2.1.5 Los registros de auditoría capturan todos los cambios en las credenciales de identificación y autenticación, incluyendo, pero no limitado a:

• Creación de nuevas cuentas.
• Elevación de privilegios.
• Todos los cambios, adiciones o supresiones de cuentas con acceso administrativo.

10.2.2 Los registros de auditoría registran los siguientes detalles para cada evento auditable:

• Identificación de usuario.
• Tipo de evento.
• Fecha y hora.
• Indicación de éxito y fracaso. Origen del evento.
• Identidad o nombre de los datos, componentes del sistema, recursos o servicios afectados (por ejemplo, nombre y protocolo).

10.4.1 Los siguientes registros de auditoría se revisan al menos una vez al día:

• Todos los eventos de seguridad.
• Registros de todos los componentes del sistema que almacenan, procesan o transmiten CHD y / o SAD.
• Registros de todos los componentes críticos del sistema.
• Registros de todos los servidores y componentes del sistema que realizan funciones de seguridad (por ejemplo, controles de seguridad de la red, sistemas de detección de intrusiones/sistemas de prevención de intrusiones (IDS/IPS), servidores de autenticación).

10.6.1 Los relojes y la hora del sistema se sincronizan utilizando tecnología de sincronización horaria.10.6.1 Los relojes y la hora del sistema se sincronizan utilizando tecnología de sincronización horaria.

10.6.2 Los sistemas están configurados a la hora correcta y consistente de la siguiente manera:

• Se están utilizando uno o varios servidores horarios designados.
• Sólo el servidor o servidores horarios centrales designados reciben la hora de fuentes externas.
• La hora recibida de fuentes externas se basa en la Hora Atómica Internacional o en la Hora Universal Coordinada (UTC).
• Los servidores horarios designados sólo aceptan actualizaciones horarias de fuentes externas específicas aceptadas por el sector.
• Cuando hay más de un servidor horario designado, los servidores horarios se comunican entre sí para mantener la hora exacta.
• Los sistemas internos sólo reciben información horaria de los servidores centrales designados.

10.6.3 La configuración de la sincronización horaria y los datos están protegidos de la siguiente manera:

• El acceso a los datos horarios está restringido únicamente al personal con una necesidad empresarial.
• Cualquier cambio en la configuración horaria de los sistemas críticos se registra, supervisa y revisa.

10.7.1 Requisito adicional solo para proveedores de servicios:

Los fallos de los sistemas críticos de control de la seguridad se detectan, alertan y abordan con prontitud, incluidos, entre otros, los fallos de los siguientes sistemas críticos de control de la seguridad:

• Controles de seguridad de la red. IDS/IPS. FIM. Soluciones antimalware.
• Controles de acceso físico.
• Controles de acceso lógicos.
• Mecanismos de registro de auditoría.
• Controles de segmentación (si se utilizan).

10.7.2 Los fallos de los sistemas críticos de control de la seguridad se detectan, alertan y abordan con prontitud, incluidos, entre otros, los fallos de los siguientes sistemas críticos de control de la seguridad:

• Controles de seguridad de la red.
• IDS/IPS.
• Mecanismos de detección de cambios.
• Soluciones antimalware.
• Controles de acceso físico.
• Controles de acceso lógicos.
• Mecanismos de registro de auditoría.
• Controles de segmentación (si se utilizan).
• Mecanismos de revisión del registro de auditoría.
• Herramientas de pruebas de seguridad automatizadas (si se utilizan).

10.7.3 Se responde con prontitud a los fallos de cualquier sistema de control de seguridad crítico, incluidos, entre otros, los siguientes:

• Restauración de funciones de seguridad.
• Identificar y documentar la duración (fecha y hora de inicio a fin) del fallo de seguridad.
• Identificar y documentar la(s) causa(s) del fallo y documentar las medidas correctoras necesarias.
• Identificar y abordar cualquier problema de seguridad que surgió durante la falla.
• Determinar si son necesarias otras acciones como resultado del fallo de seguridad.
• Implantar controles para evitar que se repita la causa del fallo.
• Reanudación del seguimiento de los controles de seguridad.

11.2.1 Los puntos de acceso inalámbricos autorizados y no autorizados se gestionan de la siguiente manera:

• Se comprueba la presencia de puntos de acceso inalámbricos (Wi-Fi), Se detectan e identifican todos los puntos de acceso inalámbricos autorizados y no autorizados, Las pruebas, la detección y la identificación se realizan al menos una vez cada tres meses.
• Si se utiliza la supervisión automatizada, se notifica al personal mediante alertas generadas.

11.3.1 Las exploraciones internas de vulnerabilidades se realizan del siguiente modo: Al menos una vez cada tres meses.

• Se resuelven las vulnerabilidades críticas y de alto riesgo (según la clasificación de riesgos de vulnerabilidad de la entidad definida en el requisito 6.3.1).
• Se realizan reexploraciones que confirman que se han resuelto todas las vulnerabilidades críticas y de alto riesgo (como se ha indicado anteriormente).
• La herramienta de exploración se mantiene actualizada con la información más reciente sobre vulnerabilidades.
• Las exploraciones son realizadas por personal cualificado y existe independencia organizativa del probador.

11.3.1.1 Todas las demás vulnerabilidades aplicables (las no clasificadas como de alto riesgo o críticas según la clasificación de riesgos de vulnerabilidad de la entidad definida en el requisito 6.3.1) se gestionan del siguiente modo:

• Se aborda en función del riesgo definido en el análisis de riesgos específico de la entidad, que se realiza de acuerdo con todos los elementos especificados en la condición 12.3.1.
• Se realizan reexploraciones cuando es necesario.
  

11.3.1.2 Las exploraciones internas de vulnerabilidades se realizan mediante exploración autenticada de la siguiente manera:

• Se documentan los sistemas que no pueden aceptar credenciales para la exploración autenticada.
• Se utilizan privilegios suficientes para aquellos sistemas que aceptan credenciales para escanear.
• Si las cuentas utilizadas para el escaneado autenticado pueden utilizarse para el inicio de sesión interactivo, se gestionan de acuerdo con el requisito 8.2.2.

11.3.1.3 Las exploraciones internas de vulnerabilidad se realizan después de cualquier cambio significativo de la siguiente manera:

• Se resuelven las vulnerabilidades críticas y de alto riesgo (según la clasificación de riesgos de vulnerabilidad de la entidad definida en el requisito 6.3.1).
• Se realizan reexploraciones cuando es necesario. Los escaneos son realizados por personal cualificado y existe independencia organizativa del probador (no se requiere que sea un QSA o ASV).

11.3.2 Las exploraciones externas de vulnerabilidades se realizan del siguiente modo: Al menos una vez cada tres meses.

• Por un proveedor de escaneado aprobado por el PCI SSC (ASV).
• Se resuelven las vulnerabilidades y se cumplen los requisitos de la Guía del Programa ASV para aprobar el escaneo.
• Los escaneos posteriores se realizan según sea necesario para confirmar que las vulnerabilidades se han resuelto de acuerdo con los requisitos de la Guía del Programa ASV para un escaneo aprobado.

11.3.2.1 Las exploraciones externas de vulnerabilidades se realizan después de cualquier cambio significativo de la siguiente manera:

• Se resuelven las vulnerabilidades que reciben una puntuación igual o superior a 4,0 en el CVSS.
• Se realizan reexploraciones cuando es necesario.
• Los escaneos son realizados por personal cualificado y existe independencia organizativa del probador (no se requiere que sea un QSA o ASV).
  

11.4 Periódicamente se realizan pruebas de penetración externas e internas y se corrigen las vulnerabilidades explotables y los puntos débiles de seguridad.

11.4.1 La entidad define, documenta y aplica una metodología de pruebas de penetración que incluye:

• Enfoques de pruebas de penetración aceptados por la industria.
• Cobertura de todo el perímetro del CDE y de los sistemas críticos.
• Pruebas desde dentro y fuera de la red.
• Pruebas para validar cualquier control de segmentación y reducción del alcance.
• Pruebas de penetración en la capa de aplicación para identificar, como mínimo, las vulnerabilidades enumeradas en el requisito 6.2.4.
• Pruebas de penetración en la capa de red que abarcan todos los componentes que soportan las funciones de red, así como los sistemas operativos.
• Revisión y consideración de las amenazas y vulnerabilidades experimentadas en los últimos 12 meses.
• Enfoque documentado para evaluar y abordar el riesgo que plantean las vulnerabilidades explotables y las deficiencias de seguridad detectadas durante las pruebas de penetración.
• Conservación de los resultados de las pruebas de penetración y de los resultados de las actividades de reparación durante al menos 12 meses.

11.4.2 Se realizan pruebas de penetración internas: Según la metodología definida por la entidad, Al menos una vez cada 12 meses Después de cualquier actualización o cambio significativo de la infraestructura o las aplicaciones Por un recurso interno cualificado o un tercero externo cualificado Existe independencia organizativa del comprobador (no es necesario que sea un QSA o ASV).

11.4.3 Se realizan pruebas de penetración externas: Según la metodología definida por la entidad Al menos una vez cada 12 meses Después de cualquier actualización o cambio significativo de la infraestructura o las aplicaciones Por un recurso interno cualificado o un tercero externo cualificado Existe independencia organizativa del comprobador (no es necesario que sea un QSA o ASV).

11.4.4 Las vulnerabilidades explotables y las debilidades de seguridad encontradas durante las pruebas de penetración se corrigen de la siguiente manera: De acuerdo con la evaluación por parte de la entidad del riesgo que plantea el problema de seguridad, tal como se define en la condición 6.3.1. Las pruebas de penetración se repiten para verificar las correcciones.

11.4.5 Si se utiliza la segmentación para aislar el CDE de otras redes, las pruebas de penetración se realizan en los controles de segmentación de la siguiente manera:

• Al menos una vez cada 12 meses y después de cualquier cambio en los controles/métodos de segmentación Cubrir todos los controles/métodos de segmentación en uso.
• Según la metodología de pruebas de penetración definida por la entidad.
• Confirmar que los controles/métodos de segmentación son operativos y eficaces, y aíslan el CDE de todos los sistemas fuera del ámbito de aplicación.
• Confirmación de la eficacia de cualquier uso del aislamiento para separar sistemas con distintos niveles de seguridad (véase la condición 2.2.3).
• Realizado por un recurso interno cualificado o un tercero externo cualificado.
• Existe independencia organizativa del probador (no es necesario que sea un QSA o ASV).

11.4.6 Requisito adicional solo para proveedores de servicios:

• Si se utiliza la segmentación para aislar el CDE de otras redes, las pruebas de penetración se realizan en los controles de segmentación de la siguiente manera: Al menos una vez cada seis meses y después de cualquier cambio en los controles/métodos de segmentación.
• Abarcar todos los controles/métodos de segmentación en uso.
• Según la metodología de pruebas de penetración definida por la entidad.
• Confirmar que los controles/métodos de segmentación son operativos y eficaces, y aíslan el CDE de todos los sistemas fuera del ámbito de aplicación.
• Confirmación de la eficacia de cualquier uso del aislamiento para separar sistemas con distintos niveles de seguridad (véase la condición 2.2.3).
• Realizado por un recurso interno cualificado o un tercero externo cualificado. Existe independencia organizativa del probador (no es necesario que sea un QSA o ASV).

11.4.7 Requisito adicional sólo para proveedores de servicios multiarrendamiento: Los proveedores de servicios multiarrendamiento apoyan a sus clientes para realizar pruebas de penetración externas según los requisitos 11.4.3 y 11.4.4.

11.5.1 Para detectar y/o prevenir intrusiones en la red se utilizan técnicas de detección y/o prevención de intrusiones:

• Todo el tráfico se controla en el perímetro del CDE.
• Todo el tráfico se controla en los puntos críticos del CDE.
• Se alerta al personal de las sospechas de compromiso.
• Todos los motores de detección y prevención de intrusiones, líneas de base y firmas se mantienen actualizados.

11.5.2 Un mecanismo de detección de cambios (por ejemplo, herramientas de supervisión de la integridad de los archivos) se despliega de la siguiente manera:

• Alertar al personal de modificaciones no autorizadas (incluidos cambios, adiciones y supresiones) de archivos críticos.
• Realizar comparaciones de archivos críticos al menos una vez por semana.
  

11.6.1 A continuación se despliega un mecanismo de detección de cambios y manipulaciones:

• Alertar al personal de modificaciones no autorizadas (incluidos indicadores de compromiso, cambios, adiciones y supresiones) en las cabeceras HTTP y en el contenido de las páginas de pago tal y como las recibe el navegador del consumidor.
• El mecanismo está configurado para evaluar el encabezado HTTP recibido y la página de pago.
• Las funciones del mecanismo se realizan del siguiente modo:
  • Al menos una vez cada siete días O
  • Periódicamente (con la frecuencia definida en el análisis de riesgos específico de la entidad, que se realiza de acuerdo con todos los elementos especificados en la condición 12.3.1).
    

12.2 Se definen y aplican políticas de uso aceptable para las tecnologías de usuario final.

12.2.1 Las políticas de uso aceptable de las tecnologías de usuario final están documentadas y se aplican, incluyendo:

• Aprobación explícita de las partes autorizadas.
• Usos aceptables de la tecnología.
• Lista de productos aprobados por la empresa para uso de los empleados, incluidos hardware y software.

12.3.1 Cada requisito de PCI DSS que ofrezca flexibilidad en cuanto a la frecuencia con la que se realiza (por ejemplo, los requisitos que deben realizarse periódicamente) está respaldado por un análisis de riesgos específico que está documentado e incluye:

• Identificación de los activos que se protegen.
• Identificación de la amenaza o amenazas contra las que protege el requisito.
• Identificación de los factores que contribuyen a la probabilidad y/o al impacto de que se materialice una amenaza.
• Análisis resultante que determina, e incluye la justificación de, con qué frecuencia debe realizarse el requisito para minimizar la probabilidad de que se materialice la amenaza.
• Revisión de cada análisis de riesgos específico al menos una vez cada 12 meses para determinar si los resultados siguen siendo válidos o si es necesario actualizar el análisis de riesgos.
• Realización de análisis de riesgos actualizados cuando sea necesario, según determine la revisión anual.

12.3.2 Se realiza un análisis de riesgos específico para cada requisito de PCI DSS que la entidad cumple con el enfoque personalizado, para incluir:

• Pruebas documentadas que detallen cada uno de los elementos especificados en el Apéndice D: Enfoque personalizado (incluyendo, como mínimo, una matriz de controles y un análisis de riesgos).
• Aprobación de las pruebas documentadas por la alta dirección.
• Realización del análisis específico de riesgos al menos una vez cada 12 meses.

12.3.3 Las suites de cifrado criptográfico y los protocolos en uso se documentan y revisan al menos una vez cada 12 meses, incluyendo como mínimo lo siguiente:

• Un inventario actualizado de todas las suites de cifrado criptográfico y protocolos en uso, incluyendo el propósito y dónde se utilizan.
• Seguimiento activo de las tendencias del sector en relación con la viabilidad continuada de todas las suites de cifrado criptográfico y protocolos en uso.
• Una estrategia documentada para responder a los cambios previstos en las vulnerabilidades criptográficas.

12.3.4 Las tecnologías de hardware y software en uso se revisan al menos una vez cada 12 meses, incluyendo como mínimo lo siguiente:

• Análisis de que las tecnologías siguen recibiendo correcciones de seguridad de los proveedores con prontitud.
• Análisis de que las tecnologías siguen respaldando (y no impiden) el cumplimiento de la norma PCI DSS por parte de la entidad.
• Documentación de cualquier anuncio o tendencia del sector relacionados con una tecnología, como cuando un proveedor ha anunciado planes de "fin de vida" para una tecnología.
• Documentación de un plan, aprobado por la alta dirección, para remediar las tecnologías obsoletas, incluidas aquellas para las que los proveedores han anunciado planes de "fin de vida".

12.4.1 Requisito adicional solo para proveedores de servicios:

• La dirección ejecutiva establece la responsabilidad de la protección de los datos de los titulares de tarjetas y un programa de cumplimiento de la norma PCI DSS que incluya:
• Responsabilidad general para mantener el cumplimiento de PCI DSS.
• Definición de un estatuto para un programa de cumplimiento de PCI DSS y comunicación a la gerencia ejecutiva.

12.4.2 Requisito adicional solo para proveedores de servicios:

• Se realizan revisiones al menos una vez cada tres meses para confirmar que el personal realiza sus tareas de acuerdo con todas las políticas de seguridad y procedimientos operativos.
• Las revisiones son realizadas por personal distinto del responsable de realizar la tarea en cuestión e incluyen, entre otras, las siguientes tareas:
  • Revisiones diarias de los registros. Revisiones de la configuración de los controles de seguridad de la red.
  • Aplicación de las normas de configuración a los nuevos sistemas.
  • Respuesta a las alertas de seguridad. Procesos de gestión del cambio.

12.4.2.1 Requisito adicional solo para proveedores de servicios: Las revisiones realizadas de acuerdo con el requisito 12.4.2 se documentan para incluir:

• Resultados de las revisiones.
• Medidas correctivas documentadas adoptadas para cualquier tarea que no se haya realizado según el requisito 12.4.2.
• Revisión y aprobación de los resultados por parte del personal asignado a la responsabilidad del programa de cumplimiento de PCI DSS.

12.5.2 La entidad documenta y confirma el alcance de la norma PCI DSS al menos una vez cada 12 meses y cuando se produce un cambio significativo en el entorno afectado. Como mínimo, la validación del alcance incluye:

• Identificar todos los flujos de datos para las distintas etapas de pago (por ejemplo, autorización, liquidación de capturas, devoluciones de cargo y reembolsos) y canales de aceptación (por ejemplo, tarjeta presente, tarjeta no presente y comercio electrónico).
• Actualización de todos los diagramas de flujo de datos según el requisito 1.2.4.
• Identificación de todas las ubicaciones en las que se almacenan, procesan y transmiten los datos de la cuenta, incluidas, entre otras, las siguientes: 1) cualquier ubicación fuera del CDE definido actualmente, 2) aplicaciones que procesan CHD, 3) transmisiones entre sistemas y redes, y 4) copias de seguridad de archivos.
• Identificación de todos los componentes del sistema en el CDE, conectados al CDE, o que podrían afectar a la seguridad del CDE.
• Identificación de todos los controles de segmentación en uso y del entorno o entornos de los que está segmentado el CDE, incluida la justificación de los entornos que quedan fuera del ámbito de aplicación.
• Identificar todas las conexiones de terceras entidades con acceso al CDE.
• Confirmar que todos los flujos de datos identificados, datos de cuentas, componentes del sistema, controles de segmentación y conexiones de terceros con acceso al CDE están incluidos en el ámbito de aplicación.

12.5.2.1 Requisito adicional solo para proveedores de servicios:

• La entidad documenta y confirma el alcance de la norma PCI DSS al menos una vez cada seis meses y cuando se produce un cambio significativo en el entorno afectado.
• Como mínimo, la validación del alcance incluye todos los elementos especificados en el requisito 12.5.2.

12.6.3 El personal recibe la siguiente formación de concienciación en materia de seguridad:

• En el momento de la contratación y al menos una vez cada 12 meses. Se utilizan múltiples métodos de comunicación.
• El personal reconoce al menos una vez cada 12 meses que ha leído y comprendido la política y los procedimientos de seguridad de la información.

12.8.2 Los acuerdos escritos con los PSVP se mantienen del siguiente modo:

• Se mantienen acuerdos escritos con todos los TPSP con los que se comparten datos de cuentas o que podrían afectar a la seguridad del CDE.
• Los acuerdos escritos incluyen el reconocimiento por parte de los proveedores de servicios de pago por terceros de que son responsables de la seguridad de los datos de las cuentas que posean o almacenen, procesen o transmitan en nombre de la entidad, o en la medida en que puedan afectar a la seguridad del CDE de la entidad.

12.9 Los proveedores de servicios a terceros (TPSP) apoyan a sus clientes en el cumplimiento de la norma PCI DSS.

12.9.1 Requisito adicional solo para proveedores de servicios: Los TPSP reconocen por escrito a los clientes que son responsables de la seguridad de los datos de la cuenta que el TPSP posee o almacena, procesa o transmite en nombre del cliente, o en la medida en que puedan afectar a la seguridad del CDE del cliente.

12.9.2 Requisito adicional solo para proveedores de servicios: Los TPSP apoyan las solicitudes de información de sus clientes para cumplir los Requisitos 12.8.4 y 12.8.5 proporcionando lo siguiente a petición del cliente:

• Información sobre el estado de cumplimiento de la PCI DSS para cualquier servicio que el PSCP realice en nombre de los clientes (requisito 12.8.4).
• Información sobre qué requisitos de la PCI DSS son responsabilidad del PSCPV y cuáles son responsabilidad del cliente, incluida cualquier responsabilidad compartida (requisito 12.8.5).

12.10.1 Existe un plan de respuesta a incidentes y está listo para activarse en caso de que se sospeche o se confirme un incidente de seguridad. El plan incluye, entre otras cosas:

• Funciones, responsabilidades y estrategias de comunicación y contacto en caso de sospecha o confirmación de un incidente de seguridad, incluida, como mínimo, la notificación a las marcas de pago y a las entidades adquirentes.
• Procedimientos de respuesta a incidentes con actividades específicas de contención y mitigación para distintos tipos de incidentes.
• Procedimientos de recuperación y continuidad empresarial.Procesos de respaldo de datos.
• Análisis de requisitos legales para reportar compromisos.
• Cobertura y respuestas de todos los componentes críticos del sistema.
• Referencia o inclusión de procedimientos de respuesta a incidentes de las marcas de pago.

12.10.2 Al menos una vez cada 12 meses, el plan de respuesta a incidentes de seguridad es:

• Se revisa y se actualiza el contenido según sea necesario.
• Comprobado, incluidos todos los elementos enumerados en la condición 12.10.1.

12.10.5 El plan de respuesta a incidentes de seguridad incluye la supervisión y la respuesta a las alertas de los sistemas de supervisión de la seguridad, incluidos, entre otros:

• Sistemas de detección y prevención de intrusiones.
• Controles de seguridad de la red.
• Mecanismos de detección de cambios en archivos críticos.
• El mecanismo de detección de cambios y manipulaciones en las páginas de pago. Este punto es una buena práctica hasta su fecha de entrada en vigor.

12.10.7 Se han establecido procedimientos de respuesta a incidentes, que se pondrán en marcha cuando se detecte PAN almacenado en cualquier lugar donde no se espere, y que incluyen:

• Determinar qué hacer si se descubre PAN fuera del CDE, incluida su recuperación, eliminación segura y/o migración al CDE definido actualmente, según proceda.
• Identificar si los datos sensibles de autenticación se almacenan con PAN.
• Determinar de dónde proceden los datos de la cuenta y cómo han acabado donde no se esperaba.
• Subsanación de fugas de datos o lagunas en los procesos que dieron lugar a que los datos de las cuentas estuvieran donde no se esperaba.