Securing digital transformation comes down to seven practices: assign clear governance, inventory what you are moving, build software securely, use zero trust access, protect data, detect and respond to attacks, and plan recovery. Mapping them to NIST CSF 2.0 keeps the program aligned with a recognized framework.
Why do transformation projects raise risk?
Moving to the cloud, adopting new platforms and connecting systems changes where data lives and who can reach it. Old controls assumed an office network. New ones must follow the data and the identity. NIST's zero trust guidance describes the shift as a response to remote users, bring your own device and cloud-based assets outside the enterprise network boundary.
The risk is not the technology itself. It is that projects move faster than the controls around them. The seven practices below add the controls into the project plan, not after it.
1. Who is accountable? Govern.
NIST CSF 2.0 organizes cybersecurity outcomes into Govern, Identify, Protect, Detect, Respond and Recover. CISA's performance goals, updated to align with CSF 2.0, added a Govern function covering leadership accountability, oversight and risk management. Name an executive owner for security in each transformation program, and require a security sign-off at the same gates as budget and legal.
2. What are you moving? Identify.
List systems, data types and owners before migration. Without that list, nothing in the old environment is secured on purpose and nothing in the new environment is secured at all. Include third parties: CISA's new goals address risks from managed service providers.
3. How is software built? Secure the pipeline.
Custom software is often the centerpiece of transformation. NIST's Secure Software Development Framework, SP 800-218, recommends a core set of high-level practices that can be integrated into any development model to reduce vulnerabilities in released software, limit the impact of those not found, and address root causes. For buyers, it also provides a common vocabulary to use with suppliers. Ask vendors how they follow it.
4. Who can access what? Zero trust.
SP 800-207 says zero trust grants no implicit trust based on network location or asset ownership, and that authentication and authorization happen before each session. Practically: MFA everywhere, least privilege, per-application access and device checks. CISA's goals added least privilege as a new item in version 2.0.
5. Where is the data? Protect it.
Classify the data being moved. Encrypt it in transit and at rest, control the keys, and keep personal data subject to privacy law, including rules on cross-border transfer, in the right places. Review storage permissions after each migration, since new cloud storage is a common source of accidental exposure.
6. Would you notice an attack? Detect and respond.
New platforms generate new logs, and they are often not turned on or collected. Before go-live, confirm that sign-ins, administrative changes and data access are logged to a central, protected store, and that someone is assigned to review alerts. CISA's goals added incident communication procedures as a new item. Write down who tells whom, and how.
7. Can you recover? Recover.
CISA's ransomware guidance says to keep offline, encrypted backups, test them, and keep infrastructure as code templates version controlled and backed up offline so cloud resources can be redeployed. Transformation often introduces new single points of failure, such as a single cloud account or one identity provider. Find them and plan around them.
What does this look like on a real project?
Constructed example. A retailer moves its order system to a cloud platform. Governance: the CIO names a security owner and requires sign-off at three gates. Identify: the team lists the 14 services involved and the data each holds. Build: the pipeline scans dependencies and tests before release. Access: staff sign in with MFA and receive per-application roles. Data: customer records are encrypted and storage is private. Detect: logs flow to a central store before go-live. Recover: a restore is tested in the new environment before the old one is turned off.
How to check or apply this
- Name an executive owner and add a security gate to the project plan.
- Build the inventory of systems, data and third parties before migrating.
- Adopt a secure development framework for the software you build, and ask suppliers about theirs.
- Require MFA, least privilege and per-application access in the new environment.
- Classify and encrypt data, then review storage permissions after each cutover.
- Turn on and test logging and alerting before go-live.
- Test restoration in the new environment before decommissioning the old one.
Safeguard can help with step 3 by scanning dependencies and showing which vulnerabilities are reachable, and with compliance automation that maps findings to frameworks. It does not certify an organization against any framework.
Quick check
Which practice should come first?
Governance. Without an owner and a gate, the other six depend on individual teams remembering to act, which rarely holds under project pressure.
Is NIST CSF 2.0 mandatory?
No. It is a voluntary framework that many organizations use to organize their programs and to communicate about risk.
Sources
- NIST Cybersecurity Framework
- CISA Cross-Sector Cybersecurity Performance Goals
- NIST SP 800-218, Secure Software Development Framework
- NIST SP 800-207, Zero Trust Architecture
- CISA #StopRansomware Guide
Last reviewed: 18 October 2026.
