Chile cybersecurity compliance gap analysis: Law 19.628, Law 21.663, and what auditors do not test
Geert WarmenbolApril 29, 2026
Key takeaways
Chilean data residency compliance under Law 19.628 is verified by auditors against primary data location. Backup configurations that mirror data to AWS US East or equivalent foreign regions are a Law 19.628 Article 4 violation that passes standard compliance review because auditors do not check disaster recovery pipelines.
Encryption at rest satisfies Chilean compliance requirements when its existence is documented. Encryption keys stored in a default Kubernetes secret on the same server as the encrypted data satisfy the compliance control and provide no practical protection — key retrieval is trivial for any attacker with server access.
Chilean regulators, particularly the Superintendencia de Bancos e Instituciones Financieras (SBIF) for financial institutions, request forensic reports in structured JSON format alongside legally required PDF summaries during breach investigations. Organizations that produce only PDF documentation face significant delays.
Law 21.663, Chile's new cybersecurity framework law passed in 2024, introduces mandatory incident reporting obligations for critical infrastructure operators and establishes the National Cybersecurity Agency (ANCI) as the primary regulatory body. Organizations operating under the prior Law 19.628 framework need to assess their obligations under the new law independently.
In Vulnox assessments of Chilean organizations, 178 days was the average time from initial compromise to discovery — consistent with environments where compliance activity is concentrated on audit preparation rather than continuous monitoring.
TL;DR
Chilean compliance frameworks check whether controls exist. They do not consistently verify whether those controls work. The backup that violates data residency exists because nobody checked the DR configuration. The encryption key stored next to the encrypted data exists because nobody tested key retrieval. The unpatched Zimbra server exists because the auditor accepted documentation of 'regular patching' without checking the version. These are not edge cases — they are the pattern. A Chile cybersecurity compliance gap analysis that does not go beyond what auditors check will miss all three.
The data residency compliance that was not
A Chilean fintech company had achieved General compliance for data residency, with documented evidence that all customer data was stored within Chile. The primary database infrastructure was hosted in AWS São Paulo. The compliance report was accurate about that. What the compliance review did not examine was the disaster recovery configuration — a backup pipeline established two years earlier that replicated the entire dataset nightly to AWS US East for redundancy. The configuration had been set up by an infrastructure engineer who had since left the company. Nobody had reviewed it since. The backup contained the complete customer dataset, including sensitive financial records covered under Law 19.628 Article 4.
The auditor verified the primary data location. The compliance badge was legitimate as far as the audit methodology went. The data was simultaneously compliant in primary storage and non-compliant in the backup pipeline that ran every night. The gap was not in the audit — it was in the assumption that 'we checked where the data is stored' and 'we know where all the data is stored' are the same question.
How Chilean compliance frameworks create structural blind spots
Chilean cybersecurity compliance operates across multiple overlapping frameworks. Law 19.628 on Protection of Private Life governs data handling generally. Law 20.584 establishes patient data protections in healthcare. Law 21.663, passed in 2024, introduced a national cybersecurity framework with mandatory incident reporting for critical infrastructure operators and established ANCI as the regulatory authority. Sector-specific regulations from SBIF, the CMF (Comisión para el Mercado Financiero), and the Superintendencia de Salud layer additional requirements on top of these base laws. The audit methodology across these frameworks shares a common characteristic: it verifies the existence of controls, not their operational effectiveness. A control that exists and is documented passes review. A control that exists, is documented, and is correctly implemented also passes review. The audit cannot distinguish between them because it is designed to check documentation, not test function.
Example
Under Law 19.628, organizations must implement appropriate technical measures to protect personal data. An auditor reviewing this requirement looks for evidence that encryption is implemented, that access controls are in place, and that security policies exist. What the audit does not do is test whether the encryption implementation is sound, whether the access controls prevent lateral movement after initial access, or whether the policies reflect what the systems actually do. The Chilean legal firm that ran Zimbra 8.8.15 — vulnerable to CVE-2022-41352, a remote code execution vulnerability with public proof-of-concept exploit code — had documentation of 'regular patching' that satisfied the audit. The version number was never checked. The vulnerability scanner was never run against the mail server. The compliance passed. The Zimbra instance was reachable from the internet and exploitable by any attacker who knew the CVE.
CVE-2022-41352 in Zimbra 8.8.15 allows unauthenticated remote code execution via a crafted archive file uploaded to the Amavis antivirus scanning component. Public exploit code has been available since late 2022. The vulnerability was actively exploited by multiple threat actor groups targeting legal and professional services firms. A compliant organization running this version with a documentation-based audit trail had no mechanism to know the exposure existed.
What assessments of Chilean organizations found that compliance reviews missed
Assessment base: Vulnox assessment data, 2023-2025, Chilean fintech, healthcare, and professional services engagements
Data residency violations in backup and DR configurations
The pattern appears consistently: primary data infrastructure is compliant with Chilean residency requirements, while disaster recovery configurations established during earlier infrastructure buildouts replicate data to US or European cloud regions. The original engineers who configured the DR pipeline are often no longer with the organization. The configuration has not been reviewed since the last infrastructure migration. Auditors verify primary data location against the system architecture documentation. The DR configuration is not in the architecture documentation because it was set up informally. The backup runs nightly. The data leaves Chile nightly.
A data residency compliance gap analysis for Chilean organizations cannot stop at verifying primary data location. Every automated data movement — backups, DR replication, log forwarding, analytics pipelines, monitoring agents — needs to be mapped against the data it carries and the destination it sends it to. The pipeline that violates Law 19.628 Article 4 is rarely the obvious one.
Encryption implemented but key management trivially bypassable
A Chilean healthcare provider implemented encryption at rest for patient records covered under Law 20.584. The encryption was documented, the compliance control was satisfied, and the audit passed. The encryption keys were stored as a default Kubernetes secret on the same server as the encrypted data. In Kubernetes, secrets stored without additional protection are base64-encoded, not encrypted — they are readable by anyone with kubectl access to the namespace. An attacker with server access, or an insider with namespace permissions, could retrieve the encryption key and decrypt the patient data in a single command sequence. The encryption existed. It provided no meaningful protection.
Chilean compliance frameworks verify that encryption is implemented. They do not verify that key management is sound. The gap between 'encryption is present' and 'encryption provides protection' is entirely in key management — where keys are stored, who can access them, and whether key access is audited. A compliance gap analysis for encryption controls has to test key retrieval, not just encryption existence.
Patching documentation accepted without version verification
A Chilean legal firm handling sensitive client data under Law 19.628 had compliance documentation indicating regular patching of its Zimbra Collaboration Suite installation. The documentation was accurate — patches had been applied to some components. The Zimbra core version had not been updated. Version 8.8.15 was running in production, exposing the organization to CVE-2022-41352. The firm's compliance submission included patch logs. The auditor did not verify the actual version string on the production system. A single authenticated scan of the mail server would have surfaced the finding in under a minute.
Patching documentation and patching reality are different things. Chilean compliance audits that accept patch logs without version verification are validating process, not outcome. Organizations that maintain meticulous patch documentation while running outdated software versions are fully compliant by audit methodology and fully exposed by operational reality. The gap analysis has to check version strings, not log entries.
The organizations most exposed under Chilean law are not the ones ignoring it
Common belief
Organizations that have invested in Chilean compliance programs — documented policies, compliance audits passed, controls implemented — have addressed the meaningful security risk. Organizations that ignore compliance are where the real exposure lives.
What we found
In assessments of Chilean organizations that held current compliance documentation, the most consistent finding was not absence of controls — it was the gap between documented control state and operational control state. Backup configurations that had drifted since the compliance review. Encryption key management that satisfied documentation requirements but failed operational testing. Patch documentation that reflected process adherence rather than version verification. The compliance documentation was accurate at the time it was produced. The operational environment had changed.
The organizations with the most undetected operational exposure are frequently those whose compliance investment was concentrated in documentation and audit preparation rather than in testing whether the documented controls function. The act of achieving compliance creates a belief that the security work is done. That belief reduces the likelihood of continued operational testing. The organization that passed its Law 19.628 audit three months ago is less likely to run a penetration test this quarter than the organization that never engaged with the compliance process. The compliance badge is the risk factor, not the protection.
What Chilean compliance audits structurally do not examine
Automated data movement outside primary storage
Chilean data residency requirements attach to data, not to primary storage systems. Backup pipelines, DR replication jobs, log forwarding configurations, monitoring agent telemetry, and analytics pipelines all move data. Each movement is a potential residency violation if the destination is outside Chile. Compliance audits verify primary storage location based on system architecture documentation. They do not enumerate automated data movements or verify destination against residency requirements. Organizations with compliant primary storage and non-compliant DR configurations are the rule, not the exception, in environments that have been running for more than two years.
SIEM configuration versus logging completeness
Chilean compliance requirements call for logging and monitoring. Organizations implement SIEM platforms — Splunk, Datadog, similar — and consider the control satisfied. The compliance gap is in what the SIEM is actually configured to ingest. Palo Alto firewalls require specific configuration to export the granular event IDs that Chilean regulators request during breach investigations. A SIEM that is running but not configured to capture those specific events produces alert volume without the forensic completeness that an SBIF investigation will require. The compliance audit verifies that a SIEM exists. The investigation verifies that it captured the right events. Those are different tests with different results.
Incident response plan testing against Chilean-specific attack patterns
Chilean compliance frameworks require incident response plans. They do not require that those plans be tested against realistic scenarios. Tabletop exercises, when they occur, tend to use generic ransomware or data breach scenarios. The specific attack patterns observed against Chilean organizations — supply chain compromises through the DTE electronic invoicing ecosystem, targeting of Transbank and payment processor integrations, credential campaigns against Chilean government contractor systems — are rarely incorporated into exercise scenarios. An IR plan tested only against generic scenarios has unknown effectiveness against the specific threat landscape Chilean organizations actually face.
Law 19.628 versus Law 21.663: two frameworks, different compliance programs
Law 19.628 (Protection of Private Life)
Chile's foundational data protection law. Covers processing of personal data by public and private entities. Establishes data subject rights and controller obligations. Data residency requirements apply to sensitive personal data. Enforcement through civil liability and regulatory action. Audit methodology is documentation-centric. Does not specify mandatory incident reporting timelines. Sector-specific regulations from SBIF and CMF layer additional requirements for financial and capital markets entities.
For most Chilean organizations, Law 19.628 has been the primary compliance framework. A gap analysis under this law needs to address what auditors check — documented controls — and what regulators investigate — operational evidence of control effectiveness. The gap between those two is where most findings live.
Law 21.663 (National Cybersecurity Framework, 2024)
Chile's new cybersecurity framework law. Establishes ANCI as the national cybersecurity authority. Introduces mandatory incident reporting obligations for critical infrastructure operators — energy, water, telecommunications, financial services, healthcare, and government systems. Sets minimum security standards for covered entities. Introduces administrative penalties for non-compliance. Reporting timeline requirements for significant incidents. Still being implemented through secondary regulation as of early 2026.
Organizations in critical infrastructure sectors have new mandatory obligations under Law 21.663 that do not exist under Law 19.628. The compliance programs are not interchangeable. A gap analysis for Law 21.663 needs to determine whether the organization falls within covered sectors, what its incident reporting obligations are under the new framework, and whether its current security controls meet the minimum standards ANCI is establishing through secondary regulation. Organizations that assume their Law 19.628 compliance posture satisfies Law 21.663 are carrying unassessed gaps.
A Chile cybersecurity compliance gap analysis that goes beyond what auditors check
- Step 1
Map all automated data movements, not just primary storage
Output:A data movement inventory mapping every automated data flow to its source system, data classification, destination region, and residency compliance status. Any flow carrying Law 19.628-covered personal data to a non-Chilean destination is a violation regardless of whether it appears in architecture documentation.
Purpose:Data residency compliance attaches to data location, not system architecture documentation. Every automated process that moves data — backup jobs, DR replication, log forwarding, monitoring telemetry, analytics pipelines — needs to be enumerated and its destination verified against Chilean residency requirements. This cannot be done from documentation alone; it requires querying actual running configurations.
- Step 2
Test encryption implementations, not just their existence
Output:A key management assessment for each encrypted data store, documenting key storage location, access requirements, and whether key retrieval is auditable. Any key stored in proximity to the data it protects — default Kubernetes secrets, application configuration files, same-server key stores — is a remediation target regardless of compliance documentation status.
Purpose:Chilean compliance audits verify that encryption is documented and implemented. They do not test whether the implementation provides meaningful protection. Key management testing needs to include: where are keys stored, who can retrieve them, what access is required to decrypt protected data, and whether key access is logged.
- Step 3
Verify patch state against running version strings, not patch logs
Output:A version verification report mapping documented patch state against actual running versions for in-scope systems. Any discrepancy is a remediation item. Any internet-facing system with a known exploitable CVE for its running version is a critical finding regardless of what the patch log says.
Purpose:Patch documentation records process adherence. Version verification records operational state. For every system in scope, compare the running version against the current patched version for that software. Discrepancies between patch logs and running versions identify systems where the patch process documented and the patch process executed are different.
- Step 4
Assess SIEM configuration against SBIF forensic evidence requirements
Output:A log coverage matrix mapping the event categories SBIF and other sector regulators request against the current SIEM ingestion configuration. Gaps become configuration remediation items. The output also documents which source systems require configuration changes to export the required event categories.
Purpose:Chilean financial regulators request specific log types and event categories during breach investigations. The SIEM needs to be configured to capture those categories from the relevant source systems before an investigation begins. Verifying SIEM completeness against the investigation evidence standard is different from verifying that a SIEM is running.
- Step 5
Determine Law 21.663 applicability and obligation scope
Output:A Law 21.663 applicability assessment documenting covered sector determination, mandatory incident reporting obligations and timelines, minimum security standard requirements under ANCI's secondary regulation, and the gap between current compliance posture and the new framework's requirements.
Purpose:Organizations in critical infrastructure sectors have obligations under Law 21.663 that did not exist under prior frameworks. The applicability determination requires assessing whether the organization's operations fall within ANCI's covered sectors and what the specific incident reporting timeline obligations are for that sector.
Where Chilean cybersecurity compliance is heading
The first significant enforcement action under Law 21.663 will involve a financial services organization whose breach reporting timeline exceeded ANCI's mandatory notification requirement — not because the organization was unaware of the obligation, but because its incident response process was not calibrated to the new timeline. This will occur within 18 months of ANCI's secondary regulation finalizing notification timeline requirements.
Law 21.663 is introducing mandatory incident reporting timelines for critical infrastructure operators for the first time in Chilean law. Organizations that have operated under Law 19.628 — which has no mandatory notification deadline — have IR processes calibrated to an open-ended standard. Recalibrating IR processes to a specific deadline requires testing the actual time from breach confirmation to notification submission. Most organizations will not run that test before the first ANCI investigation creates the pressure to do so.
Confidence: highNo enforcement action involving incident reporting timeline violations under Law 21.663 within 24 months of secondary regulation finalizing notification requirements, or ANCI guidance explicitly extending grace periods for covered entities transitioning from prior frameworks.Supply chain attacks targeting the DTE electronic invoicing ecosystem will produce at least one publicly attributed breach of a Chilean commercial organization within 24 months. The DTE system's widespread adoption across Chilean commerce creates a high-value target where a single compromised component library affects thousands of organizations simultaneously. Current General compliance requirements do not include supply chain security validation for DTE integrations.
The DTE ecosystem is used by virtually all Chilean businesses with tax obligations. The libraries and integrations connecting business systems to the SII (Servicio de Impuestos Internos) electronic invoicing platform have not been subjected to systematic security review at the ecosystem level. Supply chain attacks against widely-used financial ecosystem components have succeeded in comparable ecosystems in other markets. The conditions — widespread adoption, limited security scrutiny, compliance frameworks that do not require supply chain validation — are in place.
Confidence: mediumNo publicly attributed breach involving the DTE ecosystem within 24 months, or Chilean regulatory guidance establishing supply chain security requirements for DTE integrations before such a breach occurs.
Why the Chilean compliance gap is a pipeline problem, not a security problem
The pattern in Chilean assessments is not that organizations are ignoring security. Most have invested meaningfully in compliance programs. The problem is that the compliance program is built to produce documentation and the security program is built to satisfy the compliance program. The output of both is a set of audit-ready artifacts. What neither produces reliably is a tested, current understanding of whether the controls work. The backup that violates data residency is not the result of negligence — it is the result of a compliance program that checked documentation rather than running configurations. The encryption with trivially retrievable keys is not the result of incompetence — it is the result of an audit methodology that validated existence rather than effectiveness. I have watched the same pattern play out across fintech, healthcare, and legal environments in Chile. The compliance program is functioning exactly as designed. The design does not include operational testing, so operational testing does not happen. The gap is structural. Fixing it requires treating the compliance program as an input to the security program rather than the security program itself.
Counterargument
The counterargument is that operational testing is expensive and adds significant overhead to compliance programs that are already resource-intensive. Documentation-based compliance is a reasonable starting point for organizations that lack the resources for continuous operational validation. For small and mid-sized Chilean organizations, this argument has merit. The practical middle ground is prioritizing operational testing for the control categories where the gap between documentation and reality is most consequential: data movement pipelines, key management, and version verification. Those three test types require less resources than a full penetration test and surface the findings that documentation review consistently misses.
One thing to do this week
Pull the configuration for your disaster recovery or backup pipeline and trace where the data goes. Not where the architecture diagram says it goes — where the running job actually sends it. Check the destination region against your Law 19.628 data residency obligations. If the backup destination is outside Chile, you have a compliance gap that your last audit did not find. That is the single highest-yield check available in a Chilean compliance environment, it takes under an hour, and it surfaces the finding that matters most before a regulator does.
Further Reading
Gap Analysis
gap analysis servicesDigital Footprint
digital footprint analysisNIST Cybersecurity Framework 2.0
NIST Cybersecurity FrameworkHow to Perform Gap Analysis
gap analysis guideDigital Footprint - Canadian Cyber Centre
digital footprint best practices
Frequently Asked Questions
What are the key cybersecurity compliance requirements in Chile?
Chilean cybersecurity compliance operates across multiple frameworks. Law 19.628 on Protection of Private Life establishes data protection obligations including data residency requirements for sensitive personal data, controller accountability, and data subject rights. Law 20.584 adds patient data protections for healthcare organizations. Law 21.663, passed in 2024, introduces mandatory incident reporting for critical infrastructure operators across energy, telecommunications, financial services, healthcare, and government sectors, and establishes ANCI as the national cybersecurity authority. Sector-specific regulations from SBIF and CMF impose additional requirements on financial and capital markets entities. Organizations need to assess their obligations under each applicable framework independently — Law 21.663 compliance is not satisfied by Law 19.628 compliance.
What does a Chile cybersecurity compliance gap analysis cover?
A gap analysis for Chilean compliance should cover five areas that standard audits consistently miss: automated data movement mapping to identify backup or DR configurations that violate data residency requirements; encryption key management testing to verify that encryption provides practical protection rather than just documented existence; version verification against running systems rather than patch logs; SIEM configuration assessment against the specific event categories Chilean regulators request during investigations; and Law 21.663 applicability determination for organizations in critical infrastructure sectors. Each of these areas has produced significant findings in Vulnox assessments of Chilean organizations that had passed standard compliance reviews.
How does Law 21.663 change cybersecurity obligations for Chilean organizations?
Law 21.663, Chile's new cybersecurity framework law passed in 2024, introduces mandatory incident reporting timelines for critical infrastructure operators — a requirement that did not exist under Law 19.628. ANCI has been established as the primary cybersecurity regulatory authority with enforcement powers. Covered sectors include energy, water, telecommunications, financial services, healthcare, and government systems. Organizations in these sectors need to determine their specific obligations under ANCI's secondary regulation, which is still being finalized as of early 2026. Organizations that assume their existing Law 19.628 compliance posture satisfies Law 21.663 are carrying unassessed gaps, particularly around incident reporting timelines and minimum security standards.
What evidence do Chilean regulators request during a breach investigation?
The Superintendencia de Bancos e Instituciones Financieras (SBIF) and CMF request forensic reports in structured JSON format alongside the legally required PDF summaries during breach investigations. The JSON format allows automated analysis of incident data. Specific event categories from firewall systems — including Palo Alto-specific event IDs — are commonly requested. Organizations that produce only narrative PDF documentation or that have SIEMs configured for alert generation rather than forensic completeness face significant delays producing the required artifacts. Building the evidence infrastructure before an investigation is the only reliable way to meet response timelines.
What are the most common Law 19.628 violations found in Chilean organizations?
The most consistent Law 19.628 violation in Vulnox assessments is data residency violations in backup and DR configurations. Organizations that have achieved compliance for primary data storage routinely have automated backup pipelines that replicate data to US or European cloud regions — typically configurations established during earlier infrastructure buildouts that were never reviewed against residency requirements. The second most common finding is encryption implemented with key management that satisfies documentation requirements but provides no practical protection — encryption keys stored in default Kubernetes secrets or application configuration files on the same server as the encrypted data.
How should a Chilean organization handle incident reporting under the new Law 21.663?
Organizations in critical infrastructure sectors covered by Law 21.663 need to establish incident response processes calibrated to ANCI's mandatory notification timelines, which are being set through secondary regulation. The practical steps are: determine whether your sector falls within ANCI's covered categories, identify the specific notification timeline obligation for your sector, test your current IR process against that timeline by measuring the actual time from breach confirmation to notification submission, and identify which steps in the current process create delay. Organizations transitioning from Law 19.628 — which has no mandatory notification deadline — will likely find their IR processes are not calibrated for a specific deadline without deliberate recalibration.
Can ISO 27001 certification satisfy Chilean cybersecurity compliance requirements?
ISO 27001 provides a useful control framework that maps to many Chilean requirements, but certification does not automatically satisfy Law 19.628, Law 21.663, or sector-specific SBIF and CMF requirements. ISO 27001 does not address Chilean data residency requirements, ANCI's specific incident reporting obligations, or the evidence format requirements that Chilean regulators request during investigations. Organizations using ISO 27001 as a foundation need to supplement it with a gap analysis against Chilean-specific legal requirements — particularly data residency obligations under Law 19.628 and mandatory reporting obligations under Law 21.663 for critical infrastructure operators.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.