9. Intellectual Property, source code, and knowledge survival
The CEO of the medtech company had always been proud of the IP portfolio. Fourteen patents were defending its revolutionary medical device set to launch this year. Four years of R&D, protected and documented. But eight days after the Shock, the CEO discovered how little of it was still reachable.
The device designs lived in a cloud-only CAD platform. The engineering team had chosen it three years earlier precisely because it eliminated version-control headaches: one source of truth, always in sync, accessible from any browser. The decision had been unanimous and, at the time, obviously correct. Now the browser returned nothing. The fourteen engineers who had spent three years refining the geometry of a Class IIa medical device could describe it from memory. They could sketch it on a whiteboard. They could not manufacture it. The entire company scrambled to recover whatever they could get from the latest iteration of the design.
The quality director checked the design history file (the regulatory record required for CE marking). It was stored in a cloud-based QMS platform, US-hosted. The file documented every design input, every verification test, every risk analysis, every design review meeting. Without it, the device was not just unbuildable. It was uncertifiable.
The head of regulatory affairs tried to retrieve the technical documentation from the company's electronic document management system. Same result. Test reports from the biocompatibility studies, sterilization validations, clinical evaluation reports - all in the same platform. The physical prototypes sat on a shelf in the Grenoble office. The data proving they were safe and effective did not.
The company's IP counsel was a boutique firm in Munich, perfectly competent. But the firm used a US-hosted IP management platform to track filing deadlines, store prosecution histories, and manage the family tree of patents and continuations. The platform was unreachable. The firm's senior partner called to explain, apologetically, that a response deadline for a key patent application was in eleven days - or that’s what he thought because the docketing system was down as well.
By the end of the second week, the CEO had a manufacturing line that could not produce, a regulatory file he could not present and a patent he might lose through administrative default.
Failure Mode
Most companies prepare for data loss in their security procedures. Digital preparedness addresses a different problem: loss of access. The intellectual property still exists (on a disk, in a registry, behind an authentication wall) but the company can no longer reach, use, or prove ownership of it.
Several failure patterns are common:
- Source code inaccessibility. Code repositories hosted on a single platform (GitHub, GitLab, Bitbucket) become unreachable. Local clones may be outdated, incomplete, or nonexistent, especially as development workflows increasingly move to cloud-based environments. CI/CD configurations, which encode years of build and deployment knowledge, are typically stored within the same platform and have no independent copy.
- Build and deployment knowledge loss. Modern software is source code… plus thousands of dependencies, build configurations, environment variables, container images, and deployment scripts. When package registries (npm, PyPI, Docker Hub) are unreachable and CI/CD platforms are down, the ability to turn source code into a running system disappears. The code is readable but unbuildable.
- Cryptographic lockout. Encryption keys, signing certificates, API secrets, and license keys stored in managed key management services (AWS KMS, Azure Key Vault, GCP Cloud KMS) become inaccessible when the provider is unavailable. Data and model weights encrypted with these keys become permanently unreadable unless key material has been independently exported. Code signing certificates managed through cloud services prevent the company from shipping trusted updates.
- Machine learning and data asset loss. Trained model weights, training datasets, feature pipelines, and evaluation benchmarks stored exclusively in cloud storage are subject to the same access risks as any other cloud-hosted asset. Models that took months to train and represent significant competitive advantage can become permanently inaccessible if encrypted with provider-managed keys.
- Documentation and knowledge trapped in SaaS. Architectural decisions, operational procedures, integration specifications, and institutional knowledge accumulated over years in wikis (Notion, Confluence), issue trackers (Jira, Linear), and chat histories (Slack) vanish when these platforms go dark.
- Legal IP records inaccessible. Patent applications, trademark registrations, licensing agreements, and IP assignment documents stored exclusively in cloud-based legal-tech or contract management platforms cannot be retrieved.
- Proprietary platform lock-in for creative and technical assets. CAD files, design assets, or analytical models created in cloud-only software (Figma, certain CAD suites, proprietary analytics platforms) may be impossible to open, edit, or export outside the original tool.
- Proprietary cloud services implementing core business logic that cannot be reproduced elsewhere.
In all these scenarios, the company technically "owns" its IP. Practically, it cannot access, reproduce, prove, or use it.
Objectives
Preparedness in this area aims to ensure three things:
- Retrievability. The company must be able to retrieve its source code, critical artifacts without relying on a single platform, provider, or identity system.
- Control. The company must retain control and ownership of cryptographic material, licenses, and signing keys that define trust, authenticity, and legal authority.
- Continuity. The company must preserve operational knowledge so that systems can be understood, rebuilt, and operated under degraded conditions.
