Puntos Clave
- Las arquitecturas soberanas suelen dar prioridad a las auditorías y los controles de acceso frente a la preparación para la recuperación.
- El personal de recuperación, backup y los modelos de custodia clave pueden generar lagunas en la soberanía durante los incidentes.
- Es fundamental que los controles sean uniformes tanto en el entorno principal como en el de recuperación.
- Para lograr una resiliencia preparada para la soberanía, se necesitan procedimientos de recuperación probados en condiciones reales.
Picture the moment. The attack has already happened. The incident response team is assembling. Someone must decide which systems come back first, in what order, using the correct recovery points.
And then someone realizes: The personnel with recovery system access are based in a different country. Worse, the recovery environment itself (hosted in a cloud region, a partner datacenter, or a secondary site) was never subject to the same sovereignty controls as the primary data.
The practice wasn’t subject to the same sovereignty controls as the primary data. The regulator is asking for status. The clock is running.
This is the scenario most sovereign architectures were not designed for – and the one the Informe sobre la Readiness para la soberanía digital calls out directly: most sovereign applications are designed for the audit, not the incident.
Most sovereign applications are designed for the audit, not the incident. The difference becomes visible at the worst possible moment.
El punto ciego de la recuperación en la arquitectura soberana
Sovereignty programs are built around access control – who can reach the data, under what authority, through what pathway. That architecture is necessary. It is not sufficient. And it connects directly to the operational sovereignty gaps analizadas en la tercera entrada de esta serie: If the people who run your environment operate outside your sovereignty boundary, that problem doesn’t disappear during an incident. It becomes the problem.
What access control leaves unanswered is the harder question: What happens after an incident, when recovery is not just a technical operation but a legally constrained one?
A ransomware attack on a regulated European organization doesn’t simply create a recovery problem. It creates a recovery problem that must be solved within a jurisdiction, using personnel with appropriate authorizations, against recovery points that can be demonstrated to be clean and uncompromised.
The sovereign architecture designed to protect the data can make recovery harder if resilience wasn’t built into the original design.
Los modos de fallo específicos
The ways sovereign recovery architectures fail are predictable – and common:
- Personal de recuperación fuera de los límites de la soberanía. Los ingenieros que conocen los sistemas de Recovery pueden trabajar en otra jurisdicción. Bajo presión, recurrir a ellos es la opción más fácil. Además, supone una violación de la soberanía justo en el momento menos oportuno.
- Backup infrastructure without matching controls. Primary sovereign environments are carefully controlled. Backup infrastructure – particularly older or secondary environments – is frequently not subject to the same sovereignty requirements. If recovery points are stored or processed outside the boundary, compliant recovery is not available from compliant infrastructure.
- Key custody under crisis conditions. Hold-your-own-key arrangements are designed for normal operations. Under crisis conditions – with primary systems compromised and time pressure acute – the key custody model that works in a routine maintenance window may become an obstacle to recovery. If this hasn’t been tested, it’s an assumption, not a control.
- Cross-environment governance gaps. Organizations operating across multiple sovereign tiers – which is most of them – often have strong controls in primary environments and weaker controls in secondary environments that are also part of the recovery path. Consistency across the full estate is what auditors will look for. Gaps in secondary environments become visible exactly when consistency matters most.
Por qué los controles de soberanía pueden complicar la recuperación
The same controls that make a sovereign environment defensible to an auditor can make it harder to recover from. Data movement restrictions that prevent unauthorized exfiltration also constrain recovery orchestration. Key custody arrangements that ensure no provider can access your data without authorization also add friction when you need to restore quickly.
None of this means these controls are wrong. It means they have to be designed with recovery in mind from the start – not added to an architecture where recovery was an afterthought. This is the core of the minimum viable sovereignty principle: Calibrating controls to actual requirements includes recovery requirements, not just access control requirements.
Lo que requiere una resiliencia preparada para la soberanía
- Clean recovery validation. Proving that recovery points are free from compromise before restoring to production – not just recent, but uncompromised. In a ransomware scenario, a recent backup may itself be compromised. The ability to identify and restore from a known-clean recovery point, validated before it’s needed, is a sovereignty requirement, not just a disaster recovery requirement.
- Cross-environment governance. Consistent sovereignty controls and audit evidence across the full estate – not just the primary sovereign deployment. Every environment in the recovery path must meet the same requirements as the primary environment.
- Tested under realistic conditions. Regular exercises that validate recovery under the conditions that will actually exist during an incident: the legal constraints that apply, the personnel who are available, the recovery points that are clean. An annual disaster recovery test that doesn’t account for sovereignty constraints is not a sovereignty-ready exercise.
La pregunta que debes añadir a tu análisis sobre la soberanía
There is a direct way to assess whether your recovery architecture meets the same sovereignty requirements as your primary data environment: Ask it as a question and require an honest answer.
Can you recover your sovereign data, cleanly, within defined tolerances, using personnel operating within your sovereignty boundary, right now – under real conditions, not a controlled exercise?
For most organizations, the honest answer reveals a gap. The organizations that find it now – before the incident – will be best prepared with evidence when the regulator asks for it. The ones that don’t will be building it under pressure, in front of the people they least want to disappoint.
The Informe sobre la Readiness para la soberanía digitalincluye una pregunta sobre la evaluación de la arquitectura de recuperación directa.
Preguntas frecuentes
P: ¿Por qué es importante la recuperación para la soberanía digital?
R: La soberanía no es plena si las organizaciones no pueden recuperar los datos dentro de los mismos límites legales y operativos que se utilizan para protegerlos.
P: ¿Cuáles son los fallos más habituales en la Recovery de la soberanía?
R: Entre los fallos más habituales se encuentran que el personal de recuperación trabaje fuera de los límites de la soberanía, que backup carezca de los controles adecuados y que la gobernanza no sea coherente en todos los entornos.
P: ¿Cómo puede la custodia de las llaves complicar la Recovery?
R: Los modelos en los que tú mismo gestionas tu clave refuerzan la seguridad durante el funcionamiento normal, pero pueden ralentizar las tareas de recuperación en caso de incidentes si no se prueban adecuadamente.
P: ¿Qué es la validación de una recuperación limpia?
R: La validación de la recuperación limpia confirma que los puntos de recuperación no se han visto comprometidos antes de restaurar los sistemas. Esto es especialmente importante en casos de ransomware.
P: ¿Cómo deberían las organizaciones poner a prueba su resiliencia de cara a la soberanía?
A: They should conduct realistic exercises that account for legal constraints, operational availability, and validated recovery points – not just standard disaster recovery testing.
Alex Zinin es vicepresidente y director general del área de Proveedores de Servicios Gestionados en Commvault.
