--- title: "PCI KMO: el nuevo estándar de operaciones de gestión de llaves criptográficas del PCI SSC" description: Descubre el estándar PCI KMO, que unifica los requisitos de gestión de llaves criptográficas, mejorando la seguridad en operaciones y adaptándose a diversas implementaciones. image: https://blog.isecauditors.com/hubfs/Analisis%20de%20los%20Controles%20Organizacionales%20de%20la%20Norma%20ISOIEC%20270022022.png --- [![290x123px\_isecauditors](https://blog.isecauditors.com/hs-fs/hubfs/ISEC%20Media/Blog%20Media/290x123px_isecauditors.png?width=290&height=91&name=290x123px_isecauditors.png) ![290x123px\_isecauditors](https://blog.isecauditors.com/hs-fs/hubfs/ISEC%20Media/Blog%20Media/290x123px_isecauditors.png?width=290&height=91&name=290x123px_isecauditors.png)](https://blog.isecauditors.com/) - [← www.isecauditors.com](https://www.isecauditors.com/) - [academy.isecauditors.com](https://academy.isecauditors.com/) - [← www.isecauditors.com](https://www.isecauditors.com/) - [academy.isecauditors.com](https://academy.isecauditors.com/) [Normas PCI](https://blog.isecauditors.com/tag/normas-pci) [PCI KMO](https://blog.isecauditors.com/tag/pci-kmo) [Claves criptográficas](https://blog.isecauditors.com/tag/claves-criptográficas) # PCI KMO: el nuevo estándar de operaciones de gestión de llaves criptográficas del PCI SSC [Javier Roberto Amaya Madrid](https://blog.isecauditors.com/author/javier-roberto-amaya) 1 oct 2026, 14:29:23 El Payment Card Industry (PCI) Security Standards Council (PCI SSC) ha incorporado a su portafolio el estándar PCI Key Management Operations (PCI KMO), orientado a la seguridad de las operaciones de gestión de llaves criptográficas. El estándar define requerimientos de seguridad, procedimientos de prueba y guía para las entidades involucradas en la operación y gestión de los sistemas que usan llaves criptográficas para la seguridad de los datos de cuenta. Su propósito es servir de referencia común para la evaluación in situ de implementaciones de gestión de llaves, de modo que distintos estándares y programas del PCI SSC puedan apoyarse en un mismo conjunto de requerimientos cuando necesiten evaluar este aspecto. Aunque algunos aspectos del estándar pueden realizarse de forma remota (como la revisión documental), en general está concebido para evaluaciones in situ de las implementaciones de gestión de llaves. A diferencia de un estándar aislado, PCI KMO nace con vocación de pieza transversal del ecosistema PCI: consolida en un solo documento los requerimientos de gestión de llaves que antes vivían dispersos en otros estándares, y lo hace con un enfoque orientado a objetivos que ofrece flexibilidad a las entidades para alcanzar las metas de seguridad según su propia implementación. # Alcance del estándar El alcance de PCI KMO se define por dos dimensiones complementarias: el ciclo de vida de la llave y los elementos que la rodean. Los requerimientos de PCI KMO cubren el ciclo de vida completo de una llave criptográfica, desde su generación hasta su destrucción, así como la seguridad de los procedimientos, sistemas y equipos utilizados para gestionar y operar esas llaves durante su ciclo de vida. En cuanto a su ámbito de aplicación dentro del portafolio PCI, el estándar tiene un punto de partida deliberadamente acotado que se ampliará con el tiempo. PCI KMO está pensado para atender los requerimientos genéricos de gestión de llaves de varios estándares y programas del PCI SSC, y su foco inicial es cubrir los requerimientos de gestión de llaves contemplados por los estándares PCI PIN (Personal Identification Number) y PCI P2PE (Point-to-Point Encryption). Un aspecto central del diseño es que PCI KMO no opera de forma autónoma, sino al servicio de un “estándar o programa de referencia” (*referencing standard/program*). La aplicabilidad de cada dominio y de sus sub-requerimientos, la frecuencia con que se realiza una evaluación, y ciertos términos específicos empleados en el estándar, pueden ser definidos por el estándar o programa de referencia. Esto significa que el alcance concreto de una evaluación —qué llaves, qué sistemas, qué criptografía aceptable— lo delimita el programa que invoca a PCI KMO, mientras que los requerimientos a evaluar residen en PCI KMO. Para los usos con PCI PIN y PCI P2PE, la versión 1.0 del estándar incluye además un Apéndice B (“*Scope and Defined Terms for Specific Programs*”) que fija el alcance y los términos concretos aplicables a esos dos programas, incluyendo los tamaños mínimos de llave, los key blocks aceptables y los métodos de KCV (Key Check Value) aceptables. ![Ciclo de vida de una llave criptografica cubierto por el alcance de PCI KMO](https://blog.isecauditors.com/hs-fs/hubfs/ISEC%20Media/Blog%20Media/Ciclo%20de%20vida%20de%20una%20llave%20criptografica%20cubierto%20por%20el%20alcance%20de%20PCI%20KMO.png?width=873&height=371&name=Ciclo%20de%20vida%20de%20una%20llave%20criptografica%20cubierto%20por%20el%20alcance%20de%20PCI%20KMO.png) # Métodos aceptables para generar o cargar llaves El estándar contempla de manera explícita el conjunto de métodos por los cuales una llave criptográfica puede instalarse en un sistema. Estos métodos son los siguientes: **▪️Carga manual de llaves —** dos o más custodios ingresan componentes o shares de llave de       longitud completa mediante un proceso que impone control dual y conocimiento dividido. ▪️**Inyección de llave en claro —** una llave, normalmente una llave inicial, se transfiere de un      sistema a otro en claro. Este método no está permitido para ciertas implementaciones y      programas. **▪️Establecimiento/negociación de llave —** se emplea un protocolo criptográfico para crear una       llave compartida entre dos sistemas sin compartir valores sensibles que un intermediario       pudiera usar para derivar el valor de esa llave. **▪️Carga remota de llave (simétrica) —** una llave se transfiere entre dos sistemas cifrada bajo una       llave simétrica precompartida. ▪️**Carga remota de llave (asimétrica) —** una llave se transfiere entre dos sistemas protegida      mediante criptografía asimétrica. **▪️Generación de llave —** una llave se genera mediante un proceso aleatorio o pseudoaleatorio. **▪️Derivación de llave —** una llave se genera mediante un proceso no reversible, como una      función criptográfica de un solo sentido. **▪️Cálculo de llave —** una llave se genera mediante un proceso reversible, como el uso de      variantes. ![Metodos de generacion y de carga-establecimiento de llaves contemplados por PCI KMO](https://blog.isecauditors.com/hs-fs/hubfs/ISEC%20Media/Blog%20Media/Metodos%20de%20generacion%20y%20de%20carga-establecimiento%20de%20llaves%20contemplados%20por%20PCI%20KMO.png?width=866&height=488&name=Metodos%20de%20generacion%20y%20de%20carga-establecimiento%20de%20llaves%20contemplados%20por%20PCI%20KMO.png) # Tipos de servicio y componentes aplicables PCI KMO admite el listado de distintos tipos de servicio, que representan los servicios que una entidad puede prestar o ejecutar en el marco de la gestión de llaves. En la versión 1.0 publicada del estándar, se presentan seis tipos de servicio, y estos tipos actualmente aplican únicamente a llaves utilizadas en procesamiento de PIN o implementaciones P2PE; con el tiempo podrán añadirse tipos adicionales de componente y de llave. Los tipos definidos por el estándar son: **Decryption Management (DM) —** una entidad que gestiona el entorno de descifrado que puede soportar una solución P2PE componentizada. **PIN-Processing Service (PPS) —** una entidad que realiza operaciones de PIN (como verificación y/o traducción) y que no es el emisor de la tarjeta. **Key-Injection Facility (KIF) —** una entidad que realiza servicios criptográficos de llaves para otras entidades o tipos de servicio KMO, incluyendo, entre otros, generación, transporte y/o carga (local) de llaves. Un KIF puede incluir funciones de carga de llaves tanto locales como remotas. **Signing Service Provider (SSP) —** una entidad que provee servicios de firma de software o paquetes de datos, como firmware, aplicaciones o archivos de configuración, para otras entidades o servicios KMO. **Certification/Registration Authorities (CA/RA) —** una entidad que provee servicios de firma para llaves públicas, como certificados X.509 u otros, para uso en la distribución remota de llaves simétricas mediante técnicas asimétricas; una RA realiza servicios de registro en nombre de una CA para validar las solicitudes de certificados que la CA emitirá. **HSM-as-a-Service (HaaS) —** una entidad que gestiona un clúster de HSM (Hardware Security Module). La distinción entre los servicios de generación, transporte y carga de llaves se conserva en el nivel de los componentes P2PE a los que da soporte un servicio KMO listado (es decir, publicado en las listas de PCI SSC): un KIF puede mapear a componente P2PE KIF (si presta generación y carga de llaves), a P2PE KLCP (si solo presta carga) o a P2PE KMCP (si solo presta generación); un DM mapea a P2PE DMS, y un CA/RA mapea a P2PE CA/RA. Los tipos PPS y HaaS no mapean a ningún tipo de componente P2PE. # Relación con otros estándares PCI PCI KMO está diseñado para integrarse con el resto del portafolio PCI sin desplazarlo. Cada estándar o programa que referencia a PCI KMO puede definir individualmente qué conjuntos de requerimientos aplican, así como los sistemas y la criptografía aceptables dentro del alcance de la evaluación. El estándar es explícito en cuanto a que no sustituye a los demás: no reemplaza los requerimientos de ningún otro estándar PCI, ni constituye una recomendación del Council ni obliga a comerciantes, proveedores de servicios o instituciones financieras a adquirir o desplegar tales soluciones. Las relaciones con los distintos estándares pueden agruparse en tres clases según su naturaleza. Estándares cuya evaluación puede sustituirse por PCI KMO. En estos casos, PCI KMO está pensado para duplicar la intención de los requerimientos del otro estándar, de modo que una evaluación contra PCI KMO pueda realizarse en lugar de la evaluación original: **PCI PIN —** una evaluación contra los requerimientos de PCI KMO puede realizarse en lugar de la evaluación contra los requerimientos de PCI PIN. No obstante, en la práctica es cada marca de pago quien determina qué tipo de evaluación debe realizarse y si es posible sustituir una evaluación PCI PIN por una evaluación PCI KMO. **PCI P2PE —** PCI KMO duplica la intención de los requerimientos del Dominio 5 de PCI P2PE, de modo que puede evaluarse en lugar de los requerimientos contenidos en ese dominio. **PCI MPoC (Mobile Payments on COTS) —** PCI KMO puede servir como reemplazo de la evaluación bajo los requerimientos de PCI PIN que actualmente exige el estándar PCI MPoC cuando el producto MPoC proporciona soporte de PIN, y también puede ser adecuado para reemplazar otros requerimientos de gestión de llaves de PCI MPoC, incluyendo los usados para operaciones de Attestation and Monitoring (A&M) en una implementación xPoC (término genérico usado para las soluciones de pagos sobre dispositivos COTS, como MPoC, SPoC o CPoC). Estándares con relación independiente o complementaria **PCI DSS** (*Payment Card Industry Data Security Standard*) — existe una relación independiente entre ambos estándares. Un entorno de gestión de llaves puede ser parte de un entorno de datos del titular de la tarjeta (CDE) o estar completamente separado de cualquier CDE, y si almacena, procesa o transmite datos de cuenta queda sujeto a PCI DSS conforme a los programas de cumplimiento de las marcas de pago. PCI KMO no pretende actualmente ser un reemplazo de los requerimientos de gestión de llaves que forman parte de PCI DSS. **PCI PTS POI** (*PIN Transaction Security, Point of Interaction*) — la relación es de complemento funcional. PCI KMO aporta el detalle de cómo se aseguran las llaves criptográficas durante operaciones como la carga de llaves y operaciones criptográficas de firma y procesamiento, mientras que los estándares PCI PTS (PCI PTS POI y PCI HSM) aportan los requerimientos sobre cómo se aseguran los sistemas de pago resistentes a manipulación, en forma de dispositivos criptográficos seguros (SCD). Los aspectos de gestión de llaves propios de los despliegues de dispositivos PCI PTS POI quedan cubiertos por los programas PCI PIN y PCI P2PE, conforme a la relación descrita arriba para cada uno. Estándares sin relación directa. El estándar PCI KMO no tiene relación directa con los estándares PCI Secure Software y Secure SLC (Secure Software Lifecycle). ![Relaciones de PCI KMO con otros estandares PCI-agrupadas por tipo de relacion](https://blog.isecauditors.com/hs-fs/hubfs/ISEC%20Media/Blog%20Media/Relaciones%20de%20PCI%20KMO%20con%20otros%20estandares%20PCI-agrupadas%20por%20tipo%20de%20relacion.png?width=855&height=604&name=Relaciones%20de%20PCI%20KMO%20con%20otros%20estandares%20PCI-agrupadas%20por%20tipo%20de%20relacion.png) # Enfoque orientado a objetivos Uno de los rasgos distintivos de PCI KMO es que sus requerimientos están orientados a objetivos. Para que un enfoque orientado a objetivos sea exitoso, se espera que las entidades cuenten con una práctica robusta de gestión de riesgo como parte integral de su operación habitual. Este enfoque otorga a las entidades flexibilidad para implementar controles de seguridad con base en el riesgo identificado, pero la entidad debe poder demostrar cómo los controles implementados se sustentan en los resultados de sus prácticas de identificación y gestión de riesgo. Esta orientación se refleja en la forma en que se presenta cada requerimiento. La estructura consta de cuatro elementos: el **objetivo de seguridad** (*Security Objective*), que identifica el objetivo de seguridad de alto nivel que la entidad debe cumplir y se enuncia de manera amplia para dar flexibilidad sobre los métodos para alcanzarlo; los **requerimientos de seguridad** (*Security Requirements*), que son los controles o actividades de seguridad específicos que deben implementarse para soportar el objetivo; los **procedimientos de prueba** (*Test Procedures*), que describen las actividades de evaluación que los asesores deben realizar para validar si la entidad cumple un requerimiento; y la **guía** (*Guidance*), información adicional para ayudar a entidades y asesores a comprender la intención de cada requerimiento, que puede incluir buenas prácticas y ejemplos sin reemplazar ni extender los requerimientos a los que se refiere. Conviene destacar un matiz importante sobre el alcance de esta flexibilidad: aunque los procedimientos de prueba suelen redactarse a alto nivel para permitir flexibilidad en las evaluaciones, el estándar PCI KMO no admite un enfoque basado en riesgo para la evaluación misma, y los requerimientos deben evaluarse tal como están redactados. # Dominios del estándar y sus objetivos El estándar se organiza en cuatro dominios que abordan distintos aspectos de la seguridad de las llaves criptográficas y de su gestión. ![Mapa de los cuatro dominios de PCI KMO y sus objetivos de control](https://blog.isecauditors.com/hs-fs/hubfs/ISEC%20Media/Blog%20Media/Mapa%20de%20los%20cuatro%20dominios%20de%20PCI%20KMO%20y%20sus%20objetivos%20de%20control.png?width=889&height=753&name=Mapa%20de%20los%20cuatro%20dominios%20de%20PCI%20KMO%20y%20sus%20objetivos%20de%20control.png) ## Dominio 1 — Requerimientos núcleo (Core) Es el dominio central del estándar. El Dominio 1 es el dominio “núcleo”, que aborda el ciclo de vida de la llave desde la generación hasta la destrucción, y se utiliza además para capturar el alcance de cualquier evaluación específica de PCI KMO, incluyendo todas las llaves y sistemas empleados. Sus requerimientos aplican a todas las implementaciones de operaciones de gestión de llaves que puedan estar dentro del alcance del estándar o programa de referencia. Se compone de cuatro objetivos de control: **1A — Implementación de la gestión de llaves.** Objetivo: el alcance y los sistemas criptográficos gobernados por estos requerimientos están definidos de forma clara, precisa y completa. **1B — Generación segura de llaves.** Objetivo: las llaves criptográficas y la gestión asociada utilizada para asegurar activos sensibles se crean mediante procesos seguros que garantizan que la llave es suficientemente aleatoria y tiene la fortaleza suficiente para las operaciones que realiza. **1C — Transmisión, transporte y carga segura de llaves.** Objetivo: las llaves se aseguran siempre que son transportadas, transmitidas o cargadas. **1D — Uso y operación de llaves.** Objetivo: las llaves se usan de manera que se previene o detecta su uso no autorizado. Dentro de este dominio, el objetivo de control 1A cubre además el ciclo de vida de los dispositivos criptográficos en alcance (incluidos los SCD), no solo el de las llaves. Los sistemas en alcance se aseguran y validan antes de su uso, confirmando que no han sido objeto de modificación, sustitución, manipulación o uso indebido previo al despliegue; se gestionan de forma segura durante la operación mediante configuración segura, eliminación de valores por defecto y conexión a redes que cumplan los requerimientos de seguridad lógica; y, al final de su ciclo de despliegue o cuando se devuelven para reparación, se aseguran mediante el borrado irreversible de toda llave y material de llave secreto o privado, así como la protección contra manipulación si han de redesplegarse. Para dispositivos POI y HSM, esta validación de que no han sido manipulados implica devolverlos a su proveedor. Estos requerimientos no aplican a dispositivos COTS (*Commercial Off-The-Shelf*) de origen de transacción que formen parte de una implementación xPoC validada. ## Dominio 2 — Requerimientos de HSM remotos y HSM-as-a-Service Este dominio cubre el uso de HSMs remotos, en alineación con el estándar PCI HSM v5 publicado recientemente. Aplica tanto a HSMs gestionados y operados de forma remota por una única entidad para sus propios fines (Objetivo de control 2A), como a proveedores de HSM-as-a-Service que prestan el servicio a uno o más tenants de HSM (Objetivo de control 2B), incluyendo el caso en que el servicio se presta a un único tenant. Se mantiene la exclusión para las llaves de tenant que el proveedor de HaaS maneja en un bloque de llave cifrado, fuera de un SCD, sin capacidad de descifrarlas u operar con ellas. Contiene dos objetivos de control: **2A — HSMs remotos.** Objetivo: los HSM se gestionan de forma segura a través de redes fuera de alcance. **2B — HSM-as-a-Service (HaaS).** Objetivo: los servicios de HSM se operan de forma segura. ## Dominio 3 — Requerimientos específicos de datos y operación Este dominio cubre los requerimientos específicos para distintos tipos de activos sensibles y sistemas en alcance, como los requerimientos específicos para sistemas que aseguran datos de PIN y/o que están obligados a usar SCD, e incorpora requerimientos específicos para operaciones de CA/RA y firma, para HSMs, para criptografía realizada fuera de un SCD, y una sección opcional de buenas prácticas que no es de cumplimiento obligatorio en esta versión, aunque podría llegar a serlo en futuras revisiones del estándar. Cuando los requerimientos de este dominio entran en conflicto con los del Dominio 1, prevalecen los de este dominio. Comprende cinco objetivos de control: **3A — Requerimientos de seguridad específicos de datos.** Objetivo: los datos que requieren controles específicos se procesan de forma segura conforme a los estándares de la industria. **3B — Requerimientos de CA/RA y firma.** Objetivo: las operaciones de CA/RA y de firma se realizan de forma segura conforme a los estándares de la industria. **3C — Requerimientos de seguridad específicos de HSM.** Objetivo: los HSM se despliegan y operan de forma segura. **3D — Operaciones criptográficas fuera de un SCD.** Objetivo: la criptografía realizada fuera de un SCD se ejecuta de forma segura. Aplica solo cuando el estándar o programa de referencia permite la exposición de llaves criptográficas operativas en claro en sistemas de backend, fuera de un SCD. **3E — Requerimientos de buenas prácticas (opcional).** Objetivo: se implementan las buenas prácticas de la industria para asegurar los activos sensibles. Su evaluación y reporte es opcional: no es necesaria para obtener una validación completa de una evaluación PCI KMO en esta versión, pero algunos de estos requerimientos podrían volverse obligatorios en futuras versiones del estándar. ## Dominio 4 — Requerimientos de seguridad del entorno La seguridad física y lógica de un entorno es una parte importante de la arquitectura de seguridad general; este dominio provee distintos niveles de seguridad física que pueden aplicarse según lo requiera un requerimiento específico de KMO o el estándar o programa de referencia. El objetivo de control 4A se estructura en cinco niveles acumulativos (cada nivel superior debe cumplir, además, los requerimientos de los niveles inferiores), alineados donde es posible con ISO (International Organization for Standardization) 13491-2 (2023). Sus dos objetivos de control son: **4A — Requerimientos de entorno físico.** Se estructura en cinco niveles acumulativos: entornos mínimamente controlados (4A-1), entornos controlados (4A-2), entornos controlados-plus (4A-3), entornos seguros (4A-4), y almacenamiento y destrucción seguros (4A-5). Nota: el objetivo publicado para 4A reutiliza literalmente la redacción del objetivo 3A (“datos que requieren controles específicos”), con el agregado de “físicos”; se trata de texto vigente en la versión 1.0 del estándar. **4B — Requerimientos de entorno lógico.** Objetivo: los entornos lógicos (red, métodos de autenticación, etc.) que pueden impactar la seguridad de los activos sensibles están asegurados. Sus requerimientos están estructurados para alinearse, donde es posible, con los de PCI DSS; las implementaciones que cuenten con una evaluación PCI DSS vigente (dentro del último año) pueden reutilizar contenido y evidencias de esa evaluación, aunque el asesor debe confirmar que el alcance de dicha evaluación cubre, al menos, todo el alcance de la evaluación PCI KMO. # El programa KMO Junto con el estándar, PCI SSC publicó el PCI KMO Program Guide, que define el proceso de certificación y los roles del programa donde podemos destacar aspectos como los siguientes: **▪️Ciclo de vida de tres años.** Un listado KMO tiene una vigencia de 36 meses: aceptación inicial,       atestación anual en el año 1, atestación anual en el año 2, y reevaluación completa al finalizar       el tercer año. ▪️**Publicación en listas.** Al igual que ocurre con otros estándares PCI, los servicios KMO      validados se publican en la lista de servicios KMO validados del sitio web de PCI SSC. El      Apéndice B del Program Guide ("Elements for the List of Validated KMO Services" — distinto del      Apéndice B del propio estándar, mencionado en la sección "Alcance del estándar") detalla los     datos publicados por cada listing: nombre del proveedor, ubicación, tipo de servicio KMO,     funciones KIF soportadas, criptografía soportada, compañía asesora y fechas de atestación/     reevaluación. **▪️Evaluación y listado individual por servicio.** Aunque una misma evaluación puede cubrir varios       servicios KMO, cada uno debe reportarse en un ROV independiente: solo se listan por       separado los servicios KMO validados por una compañía asesora KMO y aceptados por PCI       SSC de forma individual — el ROV de cada servicio KMO se envía por separado al portal, y no       se aceptan envíos que agrupen varios tipos de servicio KMO. ▪️**Gestión de cambios.** Los cambios con impacto en la seguridad de un servicio KMO listado      (Delta Changes) siguen un proceso de evaluación y aceptación propio, distinto de la      reevaluación completa cada tres años.  **▪️FAQs técnicas** PCI SSC publica FAQs técnicas del estándar KMO que son de cumplimiento      obligatorio una vez publicadas y deben considerarse en toda evaluación. ▪️**Un solo asesor para cualquier evaluación.** El programa está diseñado para que un único      asesor KMO pueda realizar cualquier tipo de evaluación bajo el estándar. Los Assessor     Qualification Requirements de KMO, sin embargo, aún no se han publicado. ▪️**Sin conexión con el programa PCI PIN.** No existe conexión entre los programas de      cumplimiento PCI PIN y PCI KMO; para el detalle de cada programa de cumplimiento hay que      remitirse al CAE (Compliance Acceptance Entity) o a la marca de pago correspondiente. ▪️**Alineación con PCI HSM v5.** El estándar fue creado en alineación con los requerimientos de      PCI HSM v5, publicados recientemente, lo que explica en buena medida la ampliación del     Dominio 2 para cubrir HSMs remotos. ▪️**Alcance futuro.** PCI SSC ha indicado que futuras revisiones de PCI KMO podrían abordar      necesidades específicas de otros tipos de datos, como los cubiertos por los PCI Card      Production Standards. PCI KMO representa un paso hacia la consolidación de los requerimientos de gestión de llaves criptográficas en una referencia única, transversal a varios programas del PCI SSC. Su enfoque orientado a objetivos, su organización en cuatro dominios y su capacidad de sustituir la evaluación de estándares como PCI PIN y PCI P2PE lo posicionan como una pieza que simplifica la evaluación de la criptografía de llaves sin alterar las obligaciones de cumplimiento que cada marca de pago establece. Para las entidades que prestan servicios criptográficos —desde KIFs y proveedores de distribución de llaves hasta operadores de HSM-as-a-Service— y para los asesores, comprender su estructura y sus relaciones con el resto del ecosistema PCI será determinante para abordar las evaluaciones bajo este nuevo marco. Referencias 🔗PCI Security Standards Council. (2026). PCI Key Management and Operations (KMO) Security       Requirements and Testing Procedures, Version 1.0. PCI SSC. 🔗PCI Security Standards Council. (2023). PCI PIN Security Requirements and Testing      Procedures, Version 3.1. PCI SSC. 🔗PCI Security Standards Council. (2018). PCI Point-to-Point Encryption (P2PE) Standard, Version      3.0. PCI SSC. 🔗PCI Security Standards Council. (2024). PCI Data Security Standard (PCI DSS), Version 4.0.1.      PCI SSC. 🔗PCI Security Standards Council. (2023). PCI PIN Program Guide, Version 3.1. PCI SSC. 🔗PCI Security Standards Council. (2026). P2PE Program Guide, Version 3.2. PCI SSC. 🔗 PCI Security Standards Council. (2024). PCI DSS Program Guide, Version 4.0. PCI SSC.   - [Tweet](https://twitter.com/share) --- ![author-image](https://blog.isecauditors.com/hubfs/javier_roberto_amaya.jpg) [Javier Roberto Amaya Madrid](https://blog.isecauditors.com/author/javier-roberto-amaya) PMP, CISSP|I, CSSLP|I, CCSP, OTI, CISM, CDPSE, PCI QSA, PCI QPA, PCI SSA, PCIP, CCSK, MCPS, ITIL4, SFPC, DEPC, CSFPC, ISO 27001-LA, ISO 20000-1-IA, ISO 22301-IA Responsable de Consultoría de Colombia --- [Legal Notice](https://www.isecauditors.com/aviso-legal) [Policy Privacy](https://www.isecauditors.com/politica-privacidad) [Cookie Policy](https://www.isecauditors.com/politica-cookies) --- Copyright © 2026 - All rights reserved ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Javier Roberto Amaya Madrid", "url" : "https://blog.isecauditors.com/author/javier-roberto-amaya" }, "dateModified" : "2026-10-01T12:29:23.098Z", "datePublished" : "2026-10-01T12:29:23.000Z", "headline" : "PCI KMO: el nuevo estándar de operaciones de gestión de llaves criptográficas del PCI SSC", "image" : [ "https://blog.isecauditors.com/hubfs/Analisis%20de%20los%20Controles%20Organizacionales%20de%20la%20Norma%20ISOIEC%20270022022.png" ], "mainEntityOfPage" : { "@id" : "https://blog.isecauditors.com/pci-kmo-el-nuevo-estandar-de-operaciones-de-gestion-de-llaves-criptograficas-del-pci-ssc", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://blog.isecauditors.com/hubfs/isec_logo.png" }, "name" : "Internet Security Auditors, S.L." } } ```