I have secured it by installing it into a qube in Qubes OS.
Aside from that alone, I have my networkable Windows template set up with Windows Firewall set up maximally fascist:
a) Everything below is done in Group Policy editor (gpedit.msc).
b) I have inbound set to Block All.
c) I have outbound set to Block.
d) I have all firewall inbound and outbound profiles set to ignore local settings (Windows will override using/enabling some pre-generated rules, this stops it), do it in the same place you set Block/Block All.
e) I have DNS (port 53) outbound rule created and disabled by default, with IPs limited to just 10.139.1.0/30 for the rule (to be enabled manually in AppVM qubes).
f) I have a single rule for svchost.exe, all services, disabled by default, specifically to run Windows Update directly in the template occasionally (don't yet have a WSUS set up).
g) I created individual rules (disabled by default) for every executable I intend to use online, like Mullvad Browser.
h) IFF you are setting it up in a more traditional VM or bare metal fashion, you will need outbound DHCP rule. That rule you will need to look up elsewhere to set up properly, as I use a homebrew powershell script to occasionally query qubesdb for network config and apply it to Windows.
This is just network comms. You will need to do other things like ensuring DEP is enabled for everything, disabling all those convenience services/features like handwriting recognition and telemetry, make sure you run as a local user-privileged account, enable requiring trusted path for elevating authentication (requires Ctrl+Alt+Del when asking for admin password), etc.
Limiting network comms significantly reduces surveillance based information leaks. The TemplateVM/AppVM setup ensures that only the Template talks to Microsoft, and no state from AppVMs can be sent (as the template does not have access to them).
It is a long and arduous journey, but you might be ready for it young one...