{"id":1939,"date":"2026-03-25T17:23:39","date_gmt":"2026-03-25T16:23:39","guid":{"rendered":"https:\/\/regulated-devsecops.com\/uncategorized\/marco-de-clasificacion-de-riesgos-de-aplicaciones-para-organizaciones-reguladas\/"},"modified":"2026-03-26T09:24:12","modified_gmt":"2026-03-26T08:24:12","slug":"application-risk-classification-framework","status":"publish","type":"post","link":"https:\/\/regulated-devsecops.com\/es\/application-security-governance-es\/application-risk-classification-framework\/","title":{"rendered":"Marco de Clasificaci\u00f3n de Riesgos de Aplicaciones para Organizaciones Reguladas"},"content":{"rendered":"<h2>Por Qu\u00e9 la Clasificaci\u00f3n de Riesgos de Aplicaciones Importa para las Organizaciones Reguladas<\/h2>\n<p>Las organizaciones reguladas operan docenas \u2014 a veces cientos \u2014 de aplicaciones, cada una con un perfil de riesgo diferente. Sin un marco de clasificaci\u00f3n estructurado, los recursos de seguridad se dispersan demasiado: las aplicaciones cr\u00edticas reciben el mismo nivel de escrutinio que las utilidades internas, y los auditores encuentran imposible evaluar si los controles son proporcionales al riesgo real.<\/p>\n<p>La clasificaci\u00f3n de riesgos de aplicaciones es el fundamento que conecta el riesgo empresarial con los requisitos de controles de seguridad. Para auditores y oficiales de cumplimiento, responde a una pregunta directa: <strong>\u00bfsabe la organizaci\u00f3n qu\u00e9 aplicaciones son m\u00e1s importantes y aplica los controles en consecuencia?<\/strong><\/p>\n<p>Los reguladores esperan esto cada vez m\u00e1s. DORA (Digital Operational Resilience Act) requiere que las entidades financieras clasifiquen los activos ICT por criticidad. NIS2 exige medidas de seguridad proporcionales al riesgo. PCI DSS exige que los entornos de datos de titulares de tarjetas reciban controles mejorados. Sin un marco de clasificaci\u00f3n defendible, una organizaci\u00f3n no puede demostrar cumplimiento con ninguno de estos reg\u00edmenes.<\/p>\n<p>Un marco de clasificaci\u00f3n bien implementado tambi\u00e9n previene dos fallos comunes de auditor\u00eda: la sobreclasificaci\u00f3n (donde todo se etiqueta como \u00abcr\u00edtico\u00bb y se desperdician recursos) y la infraclasificaci\u00f3n (donde aplicaciones genuinamente cr\u00edticas se tratan como rutinarias).<\/p>\n<h2>Criterios de Clasificaci\u00f3n de Riesgos<\/h2>\n<p>Un marco de clasificaci\u00f3n robusto eval\u00faa las aplicaciones en m\u00faltiples dimensiones. Ning\u00fan criterio \u00fanico es suficiente por s\u00ed solo \u2014 la clasificaci\u00f3n debe reflejar el perfil de riesgo combinado.<\/p>\n<h3>Sensibilidad de los Datos<\/h3>\n<p>La naturaleza de los datos procesados, almacenados o transmitidos por la aplicaci\u00f3n es el principal determinante de clasificaci\u00f3n. Considere:<\/p>\n<ul>\n<li><strong>Informaci\u00f3n de Identificaci\u00f3n Personal (PII):<\/strong> Nombre, direcci\u00f3n, n\u00fameros de identificaci\u00f3n nacional, datos biom\u00e9tricos<\/li>\n<li><strong>Datos financieros:<\/strong> N\u00fameros de tarjetas de pago, datos de cuentas bancarias, registros de transacciones<\/li>\n<li><strong>Informaci\u00f3n de salud:<\/strong> Expedientes de pacientes, datos de diagn\u00f3stico, informaci\u00f3n de prescripciones<\/li>\n<li><strong>Datos empresariales confidenciales:<\/strong> Secretos comerciales, planes estrat\u00e9gicos, actividad de fusiones y adquisiciones<\/li>\n<li><strong>Credenciales de autenticaci\u00f3n:<\/strong> Contrase\u00f1as, tokens, claves API, certificados<\/li>\n<\/ul>\n<h3>Alcance Regulatorio<\/h3>\n<p>Las aplicaciones que caen dentro de mandatos regulatorios espec\u00edficos conllevan obligaciones de cumplimiento inherentes:<\/p>\n<ul>\n<li><strong>DORA:<\/strong> Sistemas ICT que apoyan funciones cr\u00edticas o importantes en servicios financieros<\/li>\n<li><strong>NIS2:<\/strong> Sistemas operados por entidades esenciales o importantes<\/li>\n<li><strong>PCI DSS:<\/strong> Cualquier sistema dentro del entorno de datos de titulares de tarjetas<\/li>\n<li><strong>GDPR:<\/strong> Sistemas que procesan datos personales de residentes de la UE<\/li>\n<li><strong>Regulaci\u00f3n sectorial espec\u00edfica:<\/strong> Salud (equivalentes a HIPAA), energ\u00eda, telecomunicaciones<\/li>\n<\/ul>\n<h3>Criticidad Empresarial<\/h3>\n<p>\u00bfQu\u00e9 tan esencial es la aplicaci\u00f3n para las operaciones empresariales continuas? Considere:<\/p>\n<ul>\n<li>Impacto en los ingresos si la aplicaci\u00f3n no est\u00e1 disponible<\/li>\n<li>Funci\u00f3n orientada al cliente vs. soporte interno<\/li>\n<li>Objetivo de Tiempo de Recuperaci\u00f3n (RTO) y Objetivo de Punto de Recuperaci\u00f3n (RPO)<\/li>\n<li>Obligaciones contractuales vinculadas a la disponibilidad de la aplicaci\u00f3n<\/li>\n<\/ul>\n<h3>Exposici\u00f3n<\/h3>\n<p>La superficie de ataque var\u00eda significativamente seg\u00fan c\u00f3mo se accede a la aplicaci\u00f3n:<\/p>\n<ul>\n<li><strong>De cara al p\u00fablico:<\/strong> Accesible desde internet sin autenticaci\u00f3n<\/li>\n<li><strong>Externo con autenticaci\u00f3n:<\/strong> Accesible por internet pero requiere inicio de sesi\u00f3n (portales de clientes, APIs de socios)<\/li>\n<li><strong>Interno:<\/strong> Disponible solo dentro de la red corporativa<\/li>\n<li><strong>Interno restringido:<\/strong> Accesible solo desde segmentos de red o estaciones de trabajo espec\u00edficos<\/li>\n<\/ul>\n<h3>Complejidad de Integraci\u00f3n<\/h3>\n<p>Las aplicaciones con numerosas integraciones conllevan un riesgo elevado porque un compromiso puede propagarse:<\/p>\n<ul>\n<li>N\u00famero de conexiones de sistemas ascendentes y descendentes<\/li>\n<li>Acceso a bases de datos compartidas o data lakes<\/li>\n<li>Exposici\u00f3n de API a terceros<\/li>\n<li>Uso de cuentas de servicio o credenciales compartidas<\/li>\n<\/ul>\n<h2>Niveles de Clasificaci\u00f3n<\/h2>\n<p>El siguiente modelo de cuatro niveles proporciona un marco pr\u00e1ctico. Las organizaciones deben adaptar los criterios espec\u00edficos a su contexto, pero debe preservarse el principio de controles diferenciados.<\/p>\n<table>\n<thead>\n<tr>\n<th>Nivel<\/th>\n<th>Etiqueta<\/th>\n<th>Criterios<\/th>\n<th>Ejemplos<\/th>\n<th>Controles Requeridos<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Nivel 1<\/strong><\/td>\n<td>Cr\u00edtico<\/td>\n<td>Procesa datos altamente sensibles (PII a escala, transacciones financieras); sujeto a m\u00faltiples mandatos regulatorios; de cara al p\u00fablico; cr\u00edtico para el negocio con RTO inferior a 4 horas; amplias integraciones con terceros<\/td>\n<td>Plataforma bancaria principal, sistema de procesamiento de pagos, portal de salud orientado al cliente, plataforma de negociaci\u00f3n<\/td>\n<td>Suite completa de pruebas de seguridad (SAST, DAST, SCA, pruebas de penetraci\u00f3n); modelado de amenazas requerido; firma de seguridad para cada versi\u00f3n; monitorizaci\u00f3n continua; revisi\u00f3n de auditor\u00eda trimestral<\/td>\n<\/tr>\n<tr>\n<td><strong>Nivel 2<\/strong><\/td>\n<td>Alto<\/td>\n<td>Procesa datos sensibles; sujeto a al menos un mandato regulatorio; de cara al exterior con autenticaci\u00f3n; impacto empresarial significativo si se ve comprometido; complejidad de integraci\u00f3n moderada<\/td>\n<td>Sistema de gesti\u00f3n de relaciones con clientes, plataforma de RRHH con PII de empleados, pasarela de API de socios, informes financieros internos<\/td>\n<td>SAST y SCA en cada compilaci\u00f3n; DAST trimestral; pruebas de penetraci\u00f3n anuales; modelo de amenazas para cambios importantes; revisi\u00f3n de seguridad para versiones significativas<\/td>\n<\/tr>\n<tr>\n<td><strong>Nivel 3<\/strong><\/td>\n<td>Moderado<\/td>\n<td>Datos sensibles limitados; alcance regulatorio directo m\u00ednimo; de cara al interior; impacto empresarial moderado; integraciones limitadas<\/td>\n<td>Herramientas internas de gesti\u00f3n de proyectos, intranet corporativa, sistema de gesti\u00f3n documental, plataformas internas de comunicaci\u00f3n<\/td>\n<td>SAST y SCA en cada compilaci\u00f3n; DAST anualmente; revisi\u00f3n de seguridad para cambios de arquitectura; gesti\u00f3n de cambios est\u00e1ndar<\/td>\n<\/tr>\n<tr>\n<td><strong>Nivel 4<\/strong><\/td>\n<td>Bajo<\/td>\n<td>Sin datos sensibles; sin alcance regulatorio directo; de cara al interior con acceso restringido; bajo impacto empresarial; sistema aislado<\/td>\n<td>Entornos sandbox de desarrollo, wikis internos con contenido no sensible, entornos de prueba (sin datos de producci\u00f3n)<\/td>\n<td>SCA para vulnerabilidades de dependencias; pr\u00e1cticas est\u00e1ndar de codificaci\u00f3n segura; revisi\u00f3n peri\u00f3dica<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>C\u00f3mo la Clasificaci\u00f3n Impulsa los Requisitos de Controles de Seguridad<\/h2>\n<p>El prop\u00f3sito completo de la clasificaci\u00f3n es crear un mapeo defendible y proporcional entre el riesgo y los controles. El principio es directo: <strong>las aplicaciones de mayor nivel requieren m\u00e1s controles, pruebas m\u00e1s frecuentes, gesti\u00f3n de cambios m\u00e1s estricta y recopilaci\u00f3n de evidencia m\u00e1s rigurosa<\/strong>.<\/p>\n<p>Este mapeo debe estar documentado en una pol\u00edtica, no dejado al criterio individual. Los auditores buscar\u00e1n un est\u00e1ndar claro y escrito que especifique qu\u00e9 controles son obligatorios en cada nivel.<\/p>\n<table>\n<thead>\n<tr>\n<th>\u00c1rea de Control<\/th>\n<th>Nivel 1 (Cr\u00edtico)<\/th>\n<th>Nivel 2 (Alto)<\/th>\n<th>Nivel 3 (Moderado)<\/th>\n<th>Nivel 4 (Bajo)<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Frecuencia SAST<\/strong><\/td>\n<td>Cada confirmaci\u00f3n \/ pull request<\/td>\n<td>Cada compilaci\u00f3n<\/td>\n<td>Cada compilaci\u00f3n<\/td>\n<td>Peri\u00f3dico \/ bajo demanda<\/td>\n<\/tr>\n<tr>\n<td><strong>Frecuencia DAST<\/strong><\/td>\n<td>Automatizado semanal + antes de cada versi\u00f3n<\/td>\n<td>Trimestral<\/td>\n<td>Anualmente<\/td>\n<td>No requerido<\/td>\n<\/tr>\n<tr>\n<td><strong>Frecuencia SCA<\/strong><\/td>\n<td>Monitorizaci\u00f3n continua<\/td>\n<td>Cada compilaci\u00f3n<\/td>\n<td>Cada compilaci\u00f3n<\/td>\n<td>Trimestral<\/td>\n<\/tr>\n<tr>\n<td><strong>Pruebas de Penetraci\u00f3n<\/strong><\/td>\n<td>Semestral (m\u00ednimo)<\/td>\n<td>Anual<\/td>\n<td>Basado en riesgos \/ bienal<\/td>\n<td>No requerido<\/td>\n<\/tr>\n<tr>\n<td><strong>Modelado de Amenazas<\/strong><\/td>\n<td>Requerido; actualizado por cambio importante<\/td>\n<td>Requerido para cambios importantes<\/td>\n<td>Recomendado<\/td>\n<td>No requerido<\/td>\n<\/tr>\n<tr>\n<td><strong>Aprobaci\u00f3n de Versiones<\/strong><\/td>\n<td>Firma del responsable de seguridad requerida<\/td>\n<td>Revisi\u00f3n de seguridad para cambios significativos<\/td>\n<td>Gesti\u00f3n de cambios est\u00e1ndar<\/td>\n<td>Gesti\u00f3n de cambios est\u00e1ndar<\/td>\n<\/tr>\n<tr>\n<td><strong>Retenci\u00f3n de Evidencia<\/strong><\/td>\n<td>7 a\u00f1os (o m\u00ednimo regulatorio)<\/td>\n<td>5 a\u00f1os<\/td>\n<td>3 a\u00f1os<\/td>\n<td>1 a\u00f1o<\/td>\n<\/tr>\n<tr>\n<td><strong>Cadencia de Revisi\u00f3n de Auditor\u00eda<\/strong><\/td>\n<td>Trimestral<\/td>\n<td>Semestral<\/td>\n<td>Anual<\/td>\n<td>Como parte de la revisi\u00f3n peri\u00f3dica del programa<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>Modelo de Gobernanza para la Clasificaci\u00f3n<\/h2>\n<p>La clasificaci\u00f3n no es un ejercicio puntual. Requiere un modelo de gobernanza que defina la propiedad, la cadencia de revisi\u00f3n y los procedimientos de escalada.<\/p>\n<h3>Qui\u00e9n Clasifica<\/h3>\n<p>El <strong>propietario de la aplicaci\u00f3n<\/strong> (normalmente un gerente de l\u00ednea de negocio o propietario del producto) propone la clasificaci\u00f3n inicial bas\u00e1ndose en los criterios anteriores. Esto no debe dejarse \u00fanicamente a los equipos de desarrollo, que pueden carecer de visibilidad sobre las dimensiones de riesgo regulatorio y empresarial.<\/p>\n<h3>Qui\u00e9n Revisa y Aprueba<\/h3>\n<p>La clasificaci\u00f3n propuesta debe ser revisada y aprobada por:<\/p>\n<ul>\n<li><strong>Equipo de Seguridad de la Informaci\u00f3n \/ Seguridad de Aplicaciones:<\/strong> Valida la evaluaci\u00f3n de riesgos t\u00e9cnicos<\/li>\n<li><strong>Funci\u00f3n de Cumplimiento \/ Riesgos:<\/strong> Confirma que el alcance regulatorio est\u00e1 correctamente identificado<\/li>\n<li><strong>Liderazgo empresarial:<\/strong> Confirma la evaluaci\u00f3n de criticidad empresarial<\/li>\n<\/ul>\n<h3>Proceso de Escalada<\/h3>\n<p>Cuando el propietario de la aplicaci\u00f3n y el equipo de seguridad no est\u00e1n de acuerdo sobre la clasificaci\u00f3n, el asunto debe escalarse al comit\u00e9 de riesgos o al CISO para la determinaci\u00f3n final. Todas las decisiones de escalada deben documentarse con su justificaci\u00f3n.<\/p>\n<h3>Disparadores de Reclasificaci\u00f3n<\/h3>\n<p>Las aplicaciones deben reclasificarse cuando:<\/p>\n<ul>\n<li>La aplicaci\u00f3n comienza a procesar una nueva categor\u00eda de datos sensibles<\/li>\n<li>Se aplica un nuevo mandato regulatorio (por ejemplo, la organizaci\u00f3n queda sujeta a DORA)<\/li>\n<li>La aplicaci\u00f3n pasa de exposici\u00f3n interna a externa<\/li>\n<li>Se produce un incidente de seguridad significativo que involucra a la aplicaci\u00f3n<\/li>\n<li>Cambios arquitect\u00f3nicos importantes alteran el perfil de integraci\u00f3n<\/li>\n<li>El ciclo de revisi\u00f3n anual identifica un cambio en la criticidad empresarial<\/li>\n<\/ul>\n<h2>Qu\u00e9 Deben Verificar los Auditores<\/h2>\n<p>Al evaluar el marco de clasificaci\u00f3n de riesgos de aplicaciones de una organizaci\u00f3n, los auditores deben verificar lo siguiente:<\/p>\n<ul>\n<li><strong>Pol\u00edtica de clasificaci\u00f3n documentada:<\/strong> Existe una pol\u00edtica formal y aprobada que define los criterios de clasificaci\u00f3n, los niveles y los requisitos de controles asociados<\/li>\n<li><strong>Inventario completo de aplicaciones:<\/strong> Todas las aplicaciones est\u00e1n clasificadas \u2014 no solo las que la organizaci\u00f3n considera importantes<\/li>\n<li><strong>Aplicaci\u00f3n coherente de criterios:<\/strong> Aplicaciones similares est\u00e1n clasificadas en el mismo nivel; no hay evidencia de clasificaci\u00f3n arbitraria o inconsistente<\/li>\n<li><strong>Los controles coinciden con el nivel:<\/strong> Tome muestras de aplicaciones en cada nivel y verifique que los controles mandatados est\u00e9n realmente en funcionamiento \u2014 no solo documentados, sino operativos<\/li>\n<li><strong>Se mantiene la cadencia de revisi\u00f3n:<\/strong> Evidencia de que las clasificaciones se revisan con la frecuencia requerida, con resultados documentados<\/li>\n<li><strong>Registros de reclasificaci\u00f3n:<\/strong> Donde las aplicaciones han sido reclasificadas, evidencia de que se identific\u00f3 el disparador, se realiz\u00f3 la revisi\u00f3n y se ajustaron los controles<\/li>\n<li><strong>Registros de gobernanza:<\/strong> Actas de reuniones de revisi\u00f3n de clasificaci\u00f3n, decisiones de escalada con justificaci\u00f3n, registros de aprobaci\u00f3n<\/li>\n<\/ul>\n<h2>Se\u00f1ales de Alerta<\/h2>\n<p>Los siguientes hallazgos deben generar preocupaci\u00f3n inmediata durante una auditor\u00eda:<\/p>\n<ul>\n<li><strong>Todas las aplicaciones clasificadas en el mismo nivel:<\/strong> Esto indica que el marco no se est\u00e1 aplicando de manera significativa. Es estad\u00edsticamente implausible que todas las aplicaciones tengan el mismo riesgo.<\/li>\n<li><strong>Sin proceso de reclasificaci\u00f3n:<\/strong> Si ninguna aplicaci\u00f3n ha sido reclasificada nunca, o el proceso no existe o la organizaci\u00f3n no est\u00e1 monitorizando los cambios en el perfil de riesgo.<\/li>\n<li><strong>Controles no diferenciados por nivel:<\/strong> Si las aplicaciones de Nivel 1 y Nivel 3 reciben pruebas de seguridad id\u00e9nticas, el marco de clasificaci\u00f3n es decorativo en lugar de operativo.<\/li>\n<li><strong>Clasificaci\u00f3n realizada \u00fanicamente por equipos de desarrollo:<\/strong> Sin aportaci\u00f3n empresarial y de cumplimiento, es probable que las clasificaciones subvaloren el riesgo regulatorio y empresarial.<\/li>\n<li><strong>Sin evidencia de supervisi\u00f3n de gobernanza:<\/strong> Existen decisiones de clasificaci\u00f3n pero no hay registro de revisi\u00f3n, cuestionamiento o aprobaci\u00f3n por parte de las funciones de seguridad o riesgos.<\/li>\n<li><strong>Clasificaciones obsoletas:<\/strong> Aplicaciones clasificadas hace dos o m\u00e1s a\u00f1os sin evidencia de revisi\u00f3n, a pesar de los cambios conocidos en el entorno.<\/li>\n<\/ul>\n<h2>Lectura Adicional<\/h2>\n<p>Para orientaci\u00f3n relacionada sobre gobernanza de seguridad de aplicaciones y pr\u00e1cticas de auditor\u00eda, consulte:<\/p>\n<ul>\n<li><a href=\"https:\/\/regulated-devsecops.com\/es\/application-security\/\">Descripci\u00f3n General de Seguridad de Aplicaciones<\/a><\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/es\/application-security-governance-es\/fundamentos-del-secure-sdlc\/\">Fundamentos del SDLC Seguro<\/a><\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/es\/regulatory-frameworks-es\/como-los-auditores-evaluan-los-controles-de-seguridad-de-aplicaciones\/\">C\u00f3mo los Auditores Eval\u00faan los Controles de Seguridad de Aplicaciones<\/a><\/li>\n<\/ul>\n<hr\/>\n<h3>Relacionado para Auditores<\/h3>\n<ul>\n<li><a href=\"https:\/\/regulated-devsecops.com\/es\/glosario\/\">Glosario<\/a> \u2014 Definiciones en lenguaje sencillo de t\u00e9rminos t\u00e9cnicos<\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/es\/regulatory-frameworks-es\/nis2-security-architecture-explained\/\">Arquitectura de Seguridad NIS2<\/a><\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/es\/regulatory-frameworks-es\/articulo-28-de-dora-explicado-gestion-del-riesgo-ict-de-terceros-en-entornos-ci-cd-y-cloud\/\">DORA Art\u00edculo 28 Explicado<\/a><\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/es\/ci-cd-governance-es\/core-ci-cd-security-controls\/\">Controles B\u00e1sicos de Seguridad CI\/CD<\/a><\/li>\n<\/ul>\n<p><em>\u00bfNuevo en la auditor\u00eda de CI\/CD? Empiece con nuestra <a href=\"https:\/\/regulated-devsecops.com\/es\/por-donde-empezar\/\">Gu\u00eda para Auditores<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Un marco estructurado de cuatro niveles para clasificar aplicaciones seg\u00fan su perfil de riesgo y aplicar controles de seguridad proporcionales. Esencial para cumplir con DORA, NIS2 y PCI DSS.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[130,135],"tags":[],"post_folder":[],"class_list":["post-1939","post","type-post","status-publish","format-standard","hentry","category-application-security-governance-es","category-regulatory-frameworks-es"],"_links":{"self":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/posts\/1939","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=1939"}],"version-history":[{"count":0,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/posts\/1939\/revisions"}],"wp:attachment":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/media?parent=1939"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/categories?post=1939"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/tags?post=1939"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/post_folder?post=1939"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}