How do we know a backup is clean before restoring it?
You cannot be certain, but you can reduce the risk considerably. Start with the timeline: from logs, endpoint data and network history, work out when the intrusion actually began, not when the encryption happened, and prefer a restore point from before that date for critical systems. Restore into an isolated environment and scan the result with up-to-date security tools, including the indicators of compromise from your investigation or from the relevant CISA advisory. Look for things that should not be there: new local or domain accounts, scheduled tasks, services and startup items, remote-access tools, and web shells on web servers. Compare the restored configuration against documentation or a known-good copy. Then watch the restored system's network behaviour before trusting it. NetSenX helps here: a restored host that begins regular outbound connections or scans other machines shows up in the alerts, while several quiet days are a useful, though not absolute, sign.