{"id":2081,"date":"2026-02-24T13:25:08","date_gmt":"2026-02-24T12:25:08","guid":{"rendered":"https:\/\/regulated-devsecops.com\/arquitectura\/"},"modified":"2026-03-26T09:50:09","modified_gmt":"2026-03-26T08:50:09","slug":"arquitectura","status":"publish","type":"page","link":"https:\/\/regulated-devsecops.com\/es\/arquitectura\/","title":{"rendered":"Arquitectura"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\"><strong>CI\/CD as a Regulated System<\/strong><\/h2>\n\n<p>In regulated environments, CI\/CD pipelines are not just automation tools.<br\/>They are <strong>enforcement systems<\/strong>.<\/p>\n\n<p>Architecture determines whether:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Security controls are <strong>mandatory<\/strong> or optional<\/li>\n\n\n<li>Policies are documented or <strong>enforced<\/strong><\/li>\n\n\n<li>Evidence is manual or <strong>system-generated<\/strong><\/li>\n\n\n<li>Compliance is reactive or <strong>continuous<\/strong><\/li>\n<\/ul>\n\n<p>This is the foundational insight for auditors: <strong>architecture is where compliance becomes technical reality.<\/strong> A well-designed pipeline makes non-compliance structurally difficult. A poorly designed one makes it structurally inevitable.<\/p>\n\n<p><em>New to these concepts? See our <a href=\"\/glossary\/\">Glossary<\/a> for plain-language definitions of CI\/CD terms.<\/em><\/p>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\"><strong>Why Architecture Comes First<\/strong><\/h2>\n\n<p>Before discussing tools, frameworks, or audits, one principle must be clear:<\/p>\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>If your architecture does not enforce controls, no checklist will save you.<\/p>\n<\/blockquote>\n\n<p>A secure CI\/CD architecture:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><strong>Prevents<\/strong> unapproved production changes \u2014 through mandatory <a href=\"\/glossary\/#rbac\">RBAC<\/a> and approval gates<\/li>\n\n\n<li><strong>Blocks<\/strong> policy violations automatically \u2014 through <a href=\"\/glossary\/#policy-as-code\">policy-as-code<\/a> enforcement<\/li>\n\n\n<li><strong>Generates<\/strong> traceable logs \u2014 for every pipeline execution, approval, and deployment<\/li>\n\n\n<li><strong>Preserves<\/strong> evidence for regulators \u2014 with immutable, timestamped records<\/li>\n\n\n<li><strong>Supports<\/strong> exit and resilience requirements \u2014 critical for <a href=\"\/compliance\/dora\/\">DORA<\/a> and <a href=\"\/compliance\/nis2\/\">NIS2<\/a><\/li>\n<\/ul>\n\n<p>Controls must be built <strong>into<\/strong> the system \u2014 not layered on top of it.<\/p>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\"><strong>What Auditors Should Assess in CI\/CD Architecture<\/strong><\/h2>\n\n<p>When reviewing CI\/CD architecture, auditors should evaluate five key questions:<\/p>\n\n<figure class=\"wp-block-table\"><table><thead><tr><th><strong>Question<\/strong><\/th><th><strong>What Good Looks Like<\/strong><\/th><th><strong>Red Flag<\/strong><\/th><\/tr><\/thead><tbody><tr><td>Can security stages be skipped?<\/td><td>All stages mandatory; no bypass without governed exception<\/td><td>Stages can be commented out or disabled by developers<\/td><\/tr><tr><td>Who can deploy to production?<\/td><td>Deployment restricted to specific roles; different from code authors<\/td><td>Anyone with repo access can trigger production deployment<\/td><\/tr><tr><td>Are pipeline configs protected?<\/td><td>Pipeline definitions in version control with change approval<\/td><td>Pipeline configs editable without review or audit trail<\/td><\/tr><tr><td>Is evidence system-generated?<\/td><td>Logs, scan results, approval records produced automatically<\/td><td>Evidence compiled manually before audits<\/td><\/tr><tr><td>Can exceptions be traced?<\/td><td>Every bypass has documented approval, reason, and expiry<\/td><td>No exception management process; suppressions ungoverned<\/td><\/tr><\/tbody><\/table><\/figure>\n\n<p>For a comprehensive assessment approach, see <a href=\"\/regulatory-frameworks\/how-auditors-actually-review-ci-cd-pipelines\/\">How Auditors Actually Review CI\/CD Pipelines<\/a>.<\/p>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\"><strong>Core Architectural Domains<\/strong><\/h2>\n\n<p>Modern regulated CI\/CD architectures rely on four foundational domains. Each domain addresses a distinct control objective that auditors verify independently.<\/p>\n\n<h3 class=\"wp-block-heading\"><strong>1. Enforcement Layer<\/strong><\/h3>\n\n<p>The enforcement layer is the <strong>control engine<\/strong> of the pipeline. It determines whether security is advisory or mandatory.<\/p>\n\n<p>It ensures:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Mandatory approval workflows \u2014 no deployment without authorised review<\/li>\n\n\n<li>Blocking policy gates \u2014 critical <a href=\"\/glossary\/#sast\">SAST<\/a>\/<a href=\"\/glossary\/#dast\">DAST<\/a>\/<a href=\"\/glossary\/#sca\">SCA<\/a> findings prevent release<\/li>\n\n\n<li>Secure build and <a href=\"\/glossary\/#artifact\">artifact<\/a> validation \u2014 signed, verified, traceable<\/li>\n\n\n<li>Role-based deployment permissions \u2014 <a href=\"\/glossary\/#segregation-of-duties\">segregation of duties<\/a> enforced by design<\/li>\n\n\n<li>Exception governance with audit trails \u2014 every override documented and time-limited<\/li>\n<\/ul>\n\n<p><strong>Without enforcement, CI\/CD becomes advisory. With enforcement, CI\/CD becomes regulated.<\/strong><\/p>\n\n<p><em>Auditor insight:<\/em> Ask to see a recent deployment that was <strong>blocked<\/strong> by a policy gate. If the organisation cannot produce one, enforcement may not be real.<\/p>\n\n<p>Deep dives:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><a href=\"\/ci-cd-governance\/ci-cd-enforcement-layer\/\">CI\/CD Enforcement Layer<\/a><\/li>\n\n\n<li><a href=\"\/ci-cd-governance\/ci-cd-based-enforcement-models\/\">CI\/CD-Based Enforcement Models<\/a><\/li>\n\n\n<li><a href=\"\/ci-cd-governance\/core-ci-cd-security-controls\/\">Core CI\/CD Security Controls<\/a><\/li>\n<\/ul>\n\n<h3 class=\"wp-block-heading\"><strong>2. Secure SDLC Integration<\/strong><\/h3>\n\n<p>Architecture must integrate security from plan to runtime \u2014 the <a href=\"\/glossary\/#shift-left\">shift-left<\/a> principle embedded in pipeline design.<\/p>\n\n<figure class=\"wp-block-table\"><table><thead><tr><th><strong>SDLC Phase<\/strong><\/th><th><strong>Security Control<\/strong><\/th><th><strong>Evidence Produced<\/strong><\/th><\/tr><\/thead><tbody><tr><td>Plan<\/td><td>Threat modelling, security requirements<\/td><td>Threat model documents, security stories<\/td><\/tr><tr><td>Code<\/td><td><a href=\"\/glossary\/#sast\">SAST<\/a>, secrets scanning, code review<\/td><td>Scan logs, review approval records<\/td><\/tr><tr><td>Build<\/td><td><a href=\"\/glossary\/#sca\">SCA<\/a>, <a href=\"\/glossary\/#sbom\">SBOM<\/a> generation, artifact signing<\/td><td>Dependency reports, SBOM files, signatures<\/td><\/tr><tr><td>Test<\/td><td><a href=\"\/glossary\/#dast\">DAST<\/a>, penetration testing<\/td><td>DAST reports, test evidence<\/td><\/tr><tr><td>Release<\/td><td>Policy gate evaluation, approval workflows<\/td><td>Gate pass\/fail logs, approval records<\/td><\/tr><tr><td>Deploy<\/td><td>Configuration validation, environment parity<\/td><td>Deployment logs, config checksums<\/td><\/tr><tr><td>Monitor<\/td><td>Runtime protection, incident detection<\/td><td>Alert logs, incident records<\/td><\/tr><\/tbody><\/table><\/figure>\n\n<p>Secure SDLC is not a compliance slogan \u2014 it is an <strong>architectural pattern<\/strong>.<\/p>\n\n<p>Deep dives:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><a href=\"\/application-security-governance\/secure-sdlc-fundamentals\/\">Secure SDLC Fundamentals<\/a><\/li>\n\n\n<li><a href=\"\/application-security-governance\/secure-sdlc-auditor-perspective\/\">Secure SDLC from the Auditor&#8217;s Perspective<\/a><\/li>\n\n\n<li><a href=\"\/regulatory-frameworks\/how-auditors-assess-application-security-controls\/\">How Auditors Assess Application Security Controls<\/a><\/li>\n<\/ul>\n\n<h3 class=\"wp-block-heading\"><strong>3. Continuous Compliance Model<\/strong><\/h3>\n\n<p>Regulated environments require compliance that is <strong>continuous, not periodic<\/strong>. The architecture must produce evidence automatically on every pipeline execution.<\/p>\n\n<ul class=\"wp-block-list\">\n<li><strong>Repeatable control execution<\/strong> \u2014 same controls, every time, every pipeline<\/li>\n\n\n<li><strong>Evidence-by-design<\/strong> \u2014 logs, reports, and approval records generated as a byproduct of normal operations<\/li>\n\n\n<li><strong>Automated traceability<\/strong> \u2014 every deployment traceable to a specific commit, review, scan, and approval<\/li>\n\n\n<li><strong>Framework mapping<\/strong> \u2014 controls mapped to <a href=\"\/compliance\/dora\/\">DORA<\/a>, <a href=\"\/compliance\/nis2\/\">NIS2<\/a>, <a href=\"\/compliance\/iso-27001\/\">ISO 27001<\/a>, <a href=\"\/compliance\/soc-2\/\">SOC 2<\/a>, <a href=\"\/compliance\/pci-dss\/\">PCI DSS<\/a><\/li>\n<\/ul>\n\n<p>A mature architecture produces compliance continuously \u2014 not quarterly.<\/p>\n\n<p>Deep dives:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><a href=\"\/regulatory-frameworks\/continuous-compliance-via-ci-cd\/\">Continuous Compliance via CI\/CD<\/a><\/li>\n\n\n<li><a href=\"\/regulatory-frameworks\/continuous-auditing-vs-point-in-time-audits\/\">Continuous Auditing vs Point-in-Time Audits<\/a><\/li>\n\n\n<li><a href=\"\/regulatory-frameworks\/dual-compliance-architecture-explained\/\">Dual-Compliance Architecture \u2014 Explained<\/a><\/li>\n\n\n<li><a href=\"\/ci-cd-governance\/building-evidence-repository-continuous-compliance\/\">Building an Evidence Repository for Continuous Compliance<\/a><\/li>\n<\/ul>\n\n<h3 class=\"wp-block-heading\"><strong>4. Security Domain Separation<\/strong><\/h3>\n\n<p>Confusion often arises between overlapping security domains. Clear architecture prevents duplication and control gaps.<\/p>\n\n<figure class=\"wp-block-table\"><table><thead><tr><th><strong>Domain<\/strong><\/th><th><strong>Focus<\/strong><\/th><th><strong>Key Concern for Auditors<\/strong><\/th><th><strong>Hub Page<\/strong><\/th><\/tr><\/thead><tbody><tr><td><strong>CI\/CD Governance<\/strong><\/td><td>Pipeline controls, enforcement, access<\/td><td>Are controls mandatory and non-bypassable?<\/td><td><a href=\"\/ci-cd-security\/\">Explore<\/a><\/td><\/tr><tr><td><strong>Application Security<\/strong><\/td><td>Code-level controls (SAST, DAST, SCA)<\/td><td>Is security testing integrated and enforced?<\/td><td><a href=\"\/application-security\/\">Explore<\/a><\/td><\/tr><tr><td><strong>DevSecOps<\/strong><\/td><td>Operating models, roles, governance<\/td><td>Who owns security? How are decisions escalated?<\/td><td><a href=\"\/devsecops\/\">Explore<\/a><\/td><\/tr><tr><td><strong>Regulatory Frameworks<\/strong><\/td><td>Compliance mapping and assurance<\/td><td>Do controls satisfy regulatory requirements?<\/td><td><a href=\"\/compliance\/\">Explore<\/a><\/td><\/tr><tr><td><strong>Audit &amp; Evidence<\/strong><\/td><td>Evidence validation, assessment<\/td><td>Is evidence trustworthy, complete, and retained?<\/td><td><a href=\"\/audit-governance\/\">Explore<\/a><\/td><\/tr><\/tbody><\/table><\/figure>\n\n<p>Understanding these domains prevents duplication and control gaps. Architecture ensures each domain has clear boundaries and responsibilities.<\/p>\n\n<p>Deep dive: <a href=\"\/resources\/security-domains-explained\/\">Security Domains Explained<\/a><\/p>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\"><strong>Architectural Maturity Model<\/strong><\/h2>\n\n<p>Regulated CI\/CD systems typically evolve across four stages. Auditors can use this model to quickly assess an organisation&#8217;s maturity level.<\/p>\n\n<figure class=\"wp-block-table\"><table><thead><tr><th><strong>Level<\/strong><\/th><th><strong>Name<\/strong><\/th><th><strong>Characteristics<\/strong><\/th><th><strong>Regulatory Readiness<\/strong><\/th><\/tr><\/thead><tbody><tr><td>1<\/td><td><strong>Automation<\/strong><\/td><td>Pipelines automate builds and deployments. Controls are optional. No evidence generation.<\/td><td>Not audit-ready. Significant gaps across all frameworks.<\/td><\/tr><tr><td>2<\/td><td><strong>Security Integration<\/strong><\/td><td>Security tools integrated (SAST\/DAST\/SCA). Results advisory, not blocking. Some logging.<\/td><td>Partially compliant. Evidence exists but enforcement is inconsistent.<\/td><\/tr><tr><td>3<\/td><td><strong>Enforced Controls<\/strong><\/td><td>Critical controls block non-compliant releases. Segregation of duties. Systematic evidence.<\/td><td>Audit-ready for most frameworks. Meets DORA\/NIS2\/ISO 27001 minimums.<\/td><\/tr><tr><td>4<\/td><td><strong>Regulated System<\/strong><\/td><td>Full traceability. Policy-as-code. Continuous compliance. Exit readiness. Predictive risk.<\/td><td>Exceeds requirements. Continuous assurance model.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n<p><strong>Regulated environments must operate at Level 3 or higher.<\/strong> Most regulatory frameworks (DORA, NIS2, ISO 27001) effectively require Level 3 as a minimum for certification or compliance.<\/p>\n\n<p>For a structured self-assessment tool, see the <a href=\"\/devsecops-operating-models\/devsecops-maturity-assessment-framework\/\">DevSecOps Maturity Assessment Framework<\/a>.<\/p>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\"><strong>Architecture vs Tooling<\/strong><\/h2>\n\n<p><strong>Tools do not create architecture.<\/strong> Architecture defines how tools are governed.<\/p>\n\n<figure class=\"wp-block-table\"><table><thead><tr><th><strong>Architecture Decides<\/strong><\/th><th><strong>Tools Implement<\/strong><\/th><\/tr><\/thead><tbody><tr><td>Which controls are mandatory<\/td><td>How scans are executed<\/td><\/tr><tr><td>Where enforcement occurs in the pipeline<\/td><td>Which vulnerabilities are detected<\/td><\/tr><tr><td>Which failures block releases<\/td><td>How results are reported<\/td><\/tr><tr><td>How evidence is retained and protected<\/td><td>Where logs are stored<\/td><\/tr><tr><td>Who can override policies<\/td><td>How exceptions are technically processed<\/td><\/tr><\/tbody><\/table><\/figure>\n\n<p>A strong architecture can change tools without losing control. A weak architecture depends entirely on vendor defaults.<\/p>\n\n<p>For auditor guidance on tool governance, see <a href=\"\/ci-cd-governance\/ci-cd-security-tooling-overview\/\">CI\/CD Security Tooling \u2014 Auditor&#8217;s Guide to Tool Categories and Controls<\/a>.<\/p>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\"><strong>Architecture &amp; Regulatory Alignment<\/strong><\/h2>\n\n<p>A well-designed CI\/CD architecture supports multiple regulatory frameworks simultaneously. Rather than adapting architecture per regulation, <strong>design architecture once \u2014 map controls many times<\/strong>.<\/p>\n\n<figure class=\"wp-block-table\"><table><thead><tr><th><strong>Framework<\/strong><\/th><th><strong>Architectural Requirement<\/strong><\/th><th><strong>Key Articles\/Controls<\/strong><\/th><th><strong>Deep Dive<\/strong><\/th><\/tr><\/thead><tbody><tr><td><strong><a href=\"\/compliance\/dora\/\">DORA<\/a><\/strong><\/td><td>ICT risk management, third-party control, resilience testing<\/td><td>Art. 9, 21, 28<\/td><td><a href=\"\/regulatory-frameworks\/dora-article-21-deep-dive-enforcing-ict-risk-controls-via-ci-cd\/\">Art. 21 Deep Dive<\/a><\/td><\/tr><tr><td><strong><a href=\"\/compliance\/nis2\/\">NIS2<\/a><\/strong><\/td><td>Supply chain security, incident readiness, risk management<\/td><td>Art. 21<\/td><td><a href=\"\/ci-cd-governance\/nis2-article-21-ci-cd-controls-mapping\/\">Art. 21 Controls Mapping<\/a><\/td><\/tr><tr><td><strong><a href=\"\/compliance\/iso-27001\/\">ISO 27001<\/a><\/strong><\/td><td>Change management, access control, secure development<\/td><td>A.8.25, A.8.28, A.8.29<\/td><td><a href=\"\/ci-cd-governance\/iso-27001-annex-a-controls-mapped-to-ci-cd-pipelines\/\">Annex A Mapping<\/a><\/td><\/tr><tr><td><strong><a href=\"\/compliance\/soc-2\/\">SOC 2<\/a><\/strong><\/td><td>Logical access, system operations, change management<\/td><td>CC6, CC7, CC8<\/td><td><a href=\"\/ci-cd-governance\/soc-2-trust-service-criteria-mapped-to-pipeline-controls\/\">TSC Mapping<\/a><\/td><\/tr><tr><td><strong><a href=\"\/compliance\/pci-dss\/\">PCI DSS<\/a><\/strong><\/td><td>Secure development, access control, logging, testing<\/td><td>Req. 6, 7, 8, 10, 11<\/td><td><a href=\"\/ci-cd-governance\/pci-dss-v4-0-software-delivery-requirements-requirement-6-deep-dive\/\">Req. 6 Deep Dive<\/a><\/td><\/tr><\/tbody><\/table><\/figure>\n\n<p>For cross-framework analysis, see the <a href=\"\/regulatory-frameworks\/iso-27001-vs-dora-vs-nis2-controls-overlap-matrix\/\">ISO 27001 vs DORA vs NIS2 Controls Overlap Matrix<\/a>.<\/p>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\"><strong>Related Architecture Deep Dives<\/strong><\/h2>\n\n<ul class=\"wp-block-list\">\n<li><a href=\"\/ci-cd-governance\/ci-cd-only-architecture-pipeline-evidence-approvals\/\">CI\/CD Only Architecture \u2014 Pipeline, Evidence &amp; Approvals<\/a><\/li>\n\n\n<li><a href=\"\/ci-cd-governance\/ci-cd-enforcement-layer\/\">CI\/CD Enforcement Layer<\/a><\/li>\n\n\n<li><a href=\"\/ci-cd-governance\/ci-cd-based-enforcement-models\/\">CI\/CD-Based Enforcement Models<\/a><\/li>\n\n\n<li><a href=\"\/regulatory-frameworks\/continuous-compliance-via-ci-cd\/\">Continuous Compliance via CI\/CD<\/a><\/li>\n\n\n<li><a href=\"\/application-security-governance\/secure-sdlc-fundamentals\/\">Secure SDLC Fundamentals<\/a><\/li>\n\n\n<li><a href=\"\/ci-cd-governance\/core-ci-cd-security-controls\/\">Core CI\/CD Security Controls<\/a><\/li>\n\n\n<li><a href=\"\/regulatory-frameworks\/dora-compliance-architecture-ci-cd-as-a-regulated-ict-system\/\">DORA Compliance Architecture \u2014 CI\/CD as a Regulated ICT System<\/a><\/li>\n\n\n<li><a href=\"\/regulatory-frameworks\/nis2-security-architecture-explained\/\">NIS2 Security Architecture Explained<\/a><\/li>\n<\/ul>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\"><strong>Final Principle<\/strong><\/h2>\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>In regulated environments, delivery speed and control are not opposites. The right architecture makes them compatible.<\/p>\n<\/blockquote>\n\n<p>If your pipeline is not designed as a control system, compliance will always be reactive. If your architecture enforces policy by design, compliance becomes continuous.<\/p>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h3 class=\"wp-block-heading\"><strong>Related for Auditors<\/strong><\/h3>\n\n<ul class=\"wp-block-list\">\n<li><a href=\"\/glossary\/\">Glossary<\/a> \u2014 Plain-language definitions of technical terms<\/li>\n\n\n<li><a href=\"\/regulatory-frameworks\/how-auditors-actually-review-ci-cd-pipelines\/\">How Auditors Actually Review CI\/CD Pipelines<\/a><\/li>\n\n\n<li><a href=\"\/ci-cd-governance\/common-audit-findings-ci-cd-top-10-failures\/\">Common Audit Findings \u2014 Top 10 CI\/CD Failures<\/a><\/li>\n\n\n<li><a href=\"\/devsecops-operating-models\/devsecops-maturity-assessment-framework\/\">DevSecOps Maturity Assessment Framework<\/a><\/li>\n<\/ul>\n\n<p><em>New to CI\/CD auditing? Start with our <a href=\"\/start-here\/\">Auditor&#8217;s Guide<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>CI\/CD as a Regulated System In regulated environments, CI\/CD pipelines are not just automation tools.They are enforcement systems. Architecture determines whether: This is the foundational insight for auditors: architecture is where compliance becomes technical reality. A well-designed pipeline makes non-compliance structurally difficult. A poorly designed one makes it structurally inevitable. New to these concepts? See &#8230; <a title=\"Arquitectura\" class=\"read-more\" href=\"https:\/\/regulated-devsecops.com\/es\/arquitectura\/\" aria-label=\"Leer m\u00e1s sobre Arquitectura\">Leer m\u00e1s<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-2081","page","type-page","status-publish"],"_links":{"self":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/pages\/2081","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/types\/page"}],"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=2081"}],"version-history":[{"count":0,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/pages\/2081\/revisions"}],"wp:attachment":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/media?parent=2081"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}