{"id":2026,"date":"2026-02-14T20:12:39","date_gmt":"2026-02-14T19:12:39","guid":{"rendered":"https:\/\/regulated-devsecops.com\/uncategorized\/dora-articulo-28-pruebas-de-estrategia-de-salida-dr-y-bcp\/"},"modified":"2026-03-26T09:33:14","modified_gmt":"2026-03-26T08:33:14","slug":"dora-article-28-exit-strategy-testing-dr-bcp","status":"publish","type":"post","link":"https:\/\/regulated-devsecops.com\/es\/regulatory-frameworks-es\/dora-article-28-exit-strategy-testing-dr-bcp\/","title":{"rendered":"DORA Art\u00edculo 28 \u2014 Pruebas de Estrategia de Salida (DR y BCP)"},"content":{"rendered":"\n<p><em>Resiliencia Operativa, Dependencia de Terceros y Desvinculaci\u00f3n Controlada<\/em><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Introducci\u00f3n<\/strong><\/h2>\n\n\n\n<p>El Art\u00edculo 28 de DORA exige a las entidades financieras que gestionen los riesgos derivados de los proveedores de servicios ICT terceros, incluidas las plataformas en la nube, los proveedores SaaS de CI\/CD, los registros de artefactos y otros servicios digitales cr\u00edticos.<\/p>\n\n\n\n<p>Un requisito central, y a menudo subestimado, es la <strong>capacidad de salir de un acuerdo con un tercero sin interrumpir las operaciones cr\u00edticas<\/strong>.<\/p>\n\n\n\n<p>La estrategia de salida no es solo una cl\u00e1usula contractual.<\/p>\n\n\n\n<p>Es una <strong>capacidad operativa probada<\/strong> integrada en la arquitectura, la gobernanza y la planificaci\u00f3n de la recuperaci\u00f3n ante desastres.<\/p>\n\n\n\n<p>Este art\u00edculo explica:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Qu\u00e9 espera el Art\u00edculo 28 de DORA respecto a las estrategias de salida<\/li>\n\n\n\n<li>C\u00f3mo la capacidad de salida se conecta con DR (Disaster Recovery) y BCP (Business Continuity Planning)<\/li>\n\n\n\n<li>C\u00f3mo probar la preparaci\u00f3n para la salida en entornos CI\/CD y dependientes de la nube<\/li>\n\n\n\n<li>Qu\u00e9 evaluar\u00e1n los auditores y reguladores<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>1. Por qu\u00e9 la estrategia de salida es un requisito central de DORA<\/strong><\/h2>\n\n\n\n<p>Bajo DORA, las entidades financieras deben:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Evitar el riesgo de concentraci\u00f3n excesiva<\/li>\n\n\n\n<li>Garantizar la continuidad de las funciones cr\u00edticas<\/li>\n\n\n\n<li>Mantener la capacidad de rescindir contratos ICT de forma segura<\/li>\n\n\n\n<li>Evitar que la dependencia del proveedor comprometa la resiliencia<\/li>\n<\/ul>\n\n\n\n<p>Una estrategia de salida garantiza que:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Un fallo del proveedor no paralice la entrega<\/li>\n\n\n\n<li>La rescisi\u00f3n de un contrato no interrumpa las operaciones<\/li>\n\n\n\n<li>Un incidente cibern\u00e9tico en un proveedor no se propague como una disrupci\u00f3n sist\u00e9mica<\/li>\n<\/ul>\n\n\n\n<p>La preparaci\u00f3n para la salida es por tanto un <strong>control de resiliencia<\/strong>, no solo una cl\u00e1usula de adquisici\u00f3n.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>2. Estrategia de salida vs Disaster Recovery vs Business Continuity<\/strong><\/h2>\n\n\n\n<p>Estos conceptos est\u00e1n relacionados pero son distintos:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Estrategia de salida<\/strong><\/h3>\n\n\n\n<p>Desvinculaci\u00f3n controlada de un proveedor tercero y transici\u00f3n a una soluci\u00f3n alternativa.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Disaster Recovery (DR)<\/strong><\/h3>\n\n\n\n<p>Restauraci\u00f3n de sistemas y servicios tras una interrupci\u00f3n.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Business Continuity Planning (BCP)<\/strong><\/h3>\n\n\n\n<p>Mantenimiento de las funciones empresariales cr\u00edticas durante y despu\u00e9s de las interrupciones.<\/p>\n\n\n\n<p>Bajo el Art\u00edculo 28 de DORA, la estrategia de salida se intersecta con DR y BCP cuando:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Un proveedor de nube deja de estar disponible<\/li>\n\n\n\n<li>Una plataforma CI\/CD SaaS est\u00e1 comprometida<\/li>\n\n\n\n<li>Un proveedor ICT cr\u00edtico falla o es sancionado<\/li>\n\n\n\n<li>Una rescisi\u00f3n de contrato requiere migraci\u00f3n<\/li>\n<\/ul>\n\n\n\n<p>La capacidad de salida debe por tanto estar t\u00e9cnicamente alineada con los mecanismos de DR y BCP.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>3. Riesgo de salida en arquitecturas CI\/CD y de nube<\/strong><\/h2>\n\n\n\n<p>Las instituciones financieras modernas dependen de:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SaaS de alojamiento Git (GitHub, GitLab, Bitbucket)<\/li>\n\n\n\n<li>Plataformas CI\/CD<\/li>\n\n\n\n<li>Registros de artefactos<\/li>\n\n\n\n<li>IaaS\/PaaS en la nube<\/li>\n\n\n\n<li>Herramientas de seguridad basadas en SaaS<\/li>\n\n\n\n<li>Proxies de dependencias<\/li>\n<\/ul>\n\n\n\n<p>Cada uno representa un posible punto \u00fanico de fallo.<\/p>\n\n\n\n<p>Los escenarios de riesgo de salida incluyen:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>P\u00e9rdida de acceso al plano de control CI\/CD<\/li>\n\n\n\n<li>Incapacidad para recuperar las configuraciones del pipeline<\/li>\n\n\n\n<li>Dependencia de formatos de artefactos propietarios<\/li>\n\n\n\n<li>Automatizaci\u00f3n de infraestructura con dependencias de proveedor<\/li>\n\n\n\n<li>P\u00e9rdida de registros de auditor\u00eda alojados por el proveedor<\/li>\n<\/ul>\n\n\n\n<p>La estrategia de salida debe por tanto integrarse en:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Dise\u00f1o de arquitectura<\/li>\n\n\n\n<li>Portabilidad de datos<\/li>\n\n\n\n<li>Exportaci\u00f3n de configuraci\u00f3n<\/li>\n\n\n\n<li>Mecanismos de copia de seguridad<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>4. Componentes principales de una estrategia de salida conforme con DORA<\/strong><\/h2>\n\n\n\n<p>Una estrategia de salida robusta incluye:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>4.1 Mapeo de activos y dependencias<\/strong><\/h3>\n\n\n\n<p>Las organizaciones deben identificar:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Qu\u00e9 funciones cr\u00edticas dependen de qu\u00e9 proveedores ICT<\/li>\n\n\n\n<li>Datos alojados externamente<\/li>\n\n\n\n<li>Titularidad de la configuraci\u00f3n<\/li>\n\n\n\n<li>Puntos de integraci\u00f3n<\/li>\n<\/ul>\n\n\n\n<p>Sin este mapeo, las pruebas de salida son imposibles.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>4.2 Portabilidad y exportaci\u00f3n de datos<\/strong><\/h3>\n\n\n\n<p>Las preguntas cr\u00edticas incluyen:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>\u00bfPueden exportarse los repositorios en formatos est\u00e1ndar?<\/li>\n\n\n\n<li>\u00bfPueden recuperarse las configuraciones de CI\/CD?<\/li>\n\n\n\n<li>\u00bfSon portables los historiales de artefactos?<\/li>\n\n\n\n<li>\u00bfPueden exportarse los registros para la retenci\u00f3n de cumplimiento?<\/li>\n<\/ul>\n\n\n\n<p>Si los registros y el historial del pipeline no pueden exportarse, la evidencia regulatoria puede perderse durante la salida.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>4.3 Preparaci\u00f3n de la soluci\u00f3n alternativa<\/strong><\/h3>\n\n\n\n<p>La salida requiere m\u00e1s que la cancelaci\u00f3n.<\/p>\n\n\n\n<p>Las organizaciones deben evaluar:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>\u00bfEst\u00e1 pre-evaluado un proveedor alternativo?<\/li>\n\n\n\n<li>\u00bfPueden redistribuirse los pipelines en otro lugar?<\/li>\n\n\n\n<li>\u00bfLas plantillas de Infraestructura como C\u00f3digo son independientes de la nube?<\/li>\n\n\n\n<li>\u00bfLas dependencias est\u00e1n en contenedores o son portables?<\/li>\n<\/ul>\n\n\n\n<p>La dependencia del proveedor es un riesgo de resiliencia bajo DORA.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>4.4 Cl\u00e1usulas contractuales<\/strong><\/h3>\n\n\n\n<p>Los contratos deben incluir:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cl\u00e1usulas de asistencia para la salida<\/li>\n\n\n\n<li>Plazos de soporte a la transici\u00f3n<\/li>\n\n\n\n<li>Requisitos de entrega de datos<\/li>\n\n\n\n<li>Garant\u00edas de retenci\u00f3n<\/li>\n\n\n\n<li>Transparencia de los subprocesadores<\/li>\n<\/ul>\n\n\n\n<p>Los auditores revisar\u00e1n si estas cl\u00e1usulas son ejecutables y est\u00e1n alineadas con los planes operativos.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>5. Pruebas de estrategia de salida en la pr\u00e1ctica<\/strong><\/h2>\n\n\n\n<p>DORA espera que las estrategias de salida sean <strong>probadas<\/strong>, no asumidas.<\/p>\n\n\n\n<p>Los enfoques de prueba pueden incluir:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>5.1 Ejercicios de mesa<\/strong><\/h3>\n\n\n\n<p>Talleres basados en escenarios que prueban:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Interrupci\u00f3n del proveedor de nube<\/li>\n\n\n\n<li>Compromiso del CI\/CD SaaS<\/li>\n\n\n\n<li>Insolvencia del proveedor<\/li>\n\n\n\n<li>Sanciones que afectan al proveedor<\/li>\n<\/ul>\n\n\n\n<p>El objetivo es validar los procesos de decisi\u00f3n y los plazos.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>5.2 Simulaci\u00f3n de migraci\u00f3n t\u00e9cnica<\/strong><\/h3>\n\n\n\n<p>Pruebas controladas como:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Exportar repositorios y volver a alojarlos<\/li>\n\n\n\n<li>Reconstruir pipelines en un entorno secundario<\/li>\n\n\n\n<li>Restaurar artefactos desde copias de seguridad independientes<\/li>\n\n\n\n<li>Desplegar aplicaciones desde un registro alternativo<\/li>\n<\/ul>\n\n\n\n<p>Estas pruebas revelan dependencias ocultas.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>5.3 Pruebas combinadas de DR + Salida<\/strong><\/h3>\n\n\n\n<p>Un enfoque maduro integra la estrategia de salida en las pruebas de DR:<\/p>\n\n\n\n<p>Escenario de ejemplo:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>\u00abEl CI\/CD SaaS principal no est\u00e1 disponible durante 72 horas.\u00bb<\/p>\n<\/blockquote>\n\n\n\n<p>Elementos de la prueba:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>\u00bfPueden continuar los despliegues?<\/li>\n\n\n\n<li>\u00bfPueden publicarse correcciones de emergencia?<\/li>\n\n\n\n<li>\u00bfSon portables las plantillas del pipeline?<\/li>\n\n\n\n<li>\u00bfSe preserva la evidencia de auditor\u00eda?<\/li>\n<\/ul>\n\n\n\n<p>Esto transforma la estrategia de salida de te\u00f3rica a operativa.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>6. Evidencia de las pruebas de estrategia de salida<\/strong><\/h2>\n\n\n\n<p>Desde una perspectiva de auditor\u00eda, las organizaciones deben producir:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Documentaci\u00f3n de la estrategia de salida<\/li>\n\n\n\n<li>Clasificaci\u00f3n de riesgos del proveedor<\/li>\n\n\n\n<li>Registros de mapeo de dependencias<\/li>\n\n\n\n<li>Informes de prueba (de mesa y t\u00e9cnicos)<\/li>\n\n\n\n<li>Brechas identificadas y planes de remediaci\u00f3n<\/li>\n\n\n\n<li>Aprobaci\u00f3n de la direcci\u00f3n sobre la preparaci\u00f3n para la salida<\/li>\n<\/ul>\n\n\n\n<p>La evidencia debe mostrar:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Las pruebas se realizaron<\/li>\n\n\n\n<li>Se identificaron debilidades<\/li>\n\n\n\n<li>Se implementaron mejoras<\/li>\n<\/ul>\n\n\n\n<p>Las pruebas sin resultados documentados no se consideran suficientes.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>7. Qu\u00e9 evaluar\u00e1n los auditores<\/strong><\/h2>\n\n\n\n<p>Los auditores verifican t\u00edpicamente:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Si los proveedores ICT cr\u00edticos est\u00e1n identificados<\/li>\n\n\n\n<li>Si las estrategias de salida est\u00e1n definidas por proveedor cr\u00edtico<\/li>\n\n\n\n<li>Si los planes de salida son realistas y t\u00e9cnicamente factibles<\/li>\n\n\n\n<li>Si las pruebas son peri\u00f3dicas y est\u00e1n documentadas<\/li>\n\n\n\n<li>Si la portabilidad de datos est\u00e1 validada<\/li>\n\n\n\n<li>Si el BCP integra escenarios de fallo de terceros<\/li>\n<\/ul>\n\n\n\n<p>Los hallazgos de auditor\u00eda comunes incluyen:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Planes de salida limitados a cl\u00e1usulas contractuales<\/li>\n\n\n\n<li>Sin validaci\u00f3n t\u00e9cnica<\/li>\n\n\n\n<li>Ning\u00fan proveedor alternativo identificado<\/li>\n\n\n\n<li>Falta de capacidad de exportaci\u00f3n de CI\/CD<\/li>\n\n\n\n<li>Ausencia de retenci\u00f3n de registros durante la transici\u00f3n del proveedor<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>8. Patrones de fallo comunes<\/strong><\/h2>\n\n\n\n<p>Las organizaciones suelen fallar porque:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Los pipelines CI\/CD son completamente gestionados por el proveedor sin proceso de exportaci\u00f3n<\/li>\n\n\n\n<li>Los registros de artefactos son propietarios sin copia de seguridad<\/li>\n\n\n\n<li>La automatizaci\u00f3n de infraestructura depende de APIs espec\u00edficas del proveedor<\/li>\n\n\n\n<li>Los escenarios de salida nunca se ensayan<\/li>\n\n\n\n<li>Las responsabilidades durante la salida no est\u00e1n claras<\/li>\n<\/ul>\n\n\n\n<p>La estrategia de salida falla cuando la arquitectura no fue dise\u00f1ada con la portabilidad en mente.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>9. Dise\u00f1o de CI\/CD para la preparaci\u00f3n de salida<\/strong><\/h2>\n\n\n\n<p>Para alinearse con el Art\u00edculo 28 de DORA, las arquitecturas CI\/CD deber\u00edan:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Usar Infraestructura como C\u00f3digo<\/li>\n\n\n\n<li>Almacenar las configuraciones del pipeline en control de versiones<\/li>\n\n\n\n<li>Mantener copias de seguridad independientes<\/li>\n\n\n\n<li>Evitar dependencias de proveedor codificadas de forma r\u00edgida<\/li>\n\n\n\n<li>Soportar compilaciones reproducibles<\/li>\n\n\n\n<li>Preservar la evidencia de cumplimiento fuera de los sistemas controlados por el proveedor<\/li>\n<\/ul>\n\n\n\n<p>La preparaci\u00f3n para la salida debe ser un principio arquitect\u00f3nico, no un ejercicio de recuperaci\u00f3n de \u00faltima hora.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Conclusi\u00f3n<\/strong><\/h2>\n\n\n\n<p>Bajo el Art\u00edculo 28 de DORA, la estrategia de salida es un control de resiliencia vinculado a:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Gesti\u00f3n de riesgos de terceros<\/li>\n\n\n\n<li>Continuidad operativa<\/li>\n\n\n\n<li>Responsabilidad regulatoria<\/li>\n<\/ul>\n\n\n\n<p>No es suficiente afirmar que la salida es posible.<\/p>\n\n\n\n<p>Las organizaciones deben demostrar que:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>La salida es t\u00e9cnicamente factible<\/li>\n\n\n\n<li>Las dependencias son conocidas<\/li>\n\n\n\n<li>Existen rutas alternativas<\/li>\n\n\n\n<li>Se han realizado pruebas<\/li>\n\n\n\n<li>La evidencia se conserva<\/li>\n<\/ul>\n\n\n\n<p>En entornos regulados, la resiliencia incluye la capacidad de salir.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Art\u00edculos relacionados<\/strong><\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora-article-28-architecture-third-party-risk-controls-across-ci-cd-pipelines\/\" data-type=\"post\" data-id=\"364\"><strong>DORA Article 28 \u2014 Architecture<\/strong><\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora-article-28-auditor-checklist-yes-no-evidence\/\" data-type=\"post\" data-id=\"353\"><strong>DORA Article 28 \u2014 Auditor Checklist<\/strong><\/a><\/li>\n\n\n\n<li><strong><a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora-article-28-evidence-pack-what-to-show-auditors\/\" data-type=\"post\" data-id=\"347\">DORA Article 28 \u2014 Evidence Pack<\/a><\/strong><\/li>\n\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora-article-28-mapping-controls-to-evidence\/\" data-type=\"post\" data-id=\"356\"><strong>DORA Article 28 \u2014 CI\/CD Controls Mapping<\/strong><\/a><\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n    <section class=\"rds-author-box rds-author-box--audit\"\r\n             dir=\"ltr\" lang=\"es\"\r\n             style=\"border:1px solid rgba(100,116,139,.35);border-radius:14px;padding:16px 18px;margin:26px 0 18px;background:rgba(148,163,184,.08);\">\r\n      <strong style=\"margin:0 0 8px; font-size:14px; font-weight:700; letter-spacing:.02em;\">Contexto \u201caudit-ready\u201d<\/strong>\r\n      <p style=\"margin:0; font-size:14px; line-height:1.55;\">Contenido pensado para entornos regulados: controles antes que herramientas, enforcement en CI\/CD y evidencia por dise\u00f1o para auditor\u00edas.<\/p>\r\n      <p style=\"margin:0; font-size:14px; line-height:1.55;\">Enfoque en trazabilidad, aprobaciones, gobernanza de excepciones y retenci\u00f3n de evidencia de extremo a extremo.<\/p>\r\n      <p style=\"margin:0; font-size:14px; line-height:1.55;\">\r\n        <a href=\"https:\/\/regulated-devsecops.com\/es\/es\/about\/\">Ver la metodolog\u00eda en la p\u00e1gina About.<\/a>\r\n      <\/p>\r\n    <\/section>\r\n    \n","protected":false},"excerpt":{"rendered":"<p>El Art\u00edculo 28 de DORA exige que las entidades financieras prueben su capacidad de desvinculaci\u00f3n de proveedores ICT terceros, integrando la estrategia de salida con DR y BCP como control de resiliencia.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[135],"tags":[],"post_folder":[],"class_list":["post-2026","post","type-post","status-publish","format-standard","hentry","category-regulatory-frameworks-es"],"_links":{"self":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/posts\/2026","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/comments?post=2026"}],"version-history":[{"count":0,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/posts\/2026\/revisions"}],"wp:attachment":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/media?parent=2026"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/categories?post=2026"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/tags?post=2026"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/post_folder?post=2026"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}