This is something that's a problem for my organisation. Here are some things we do to make it less problematic:
Use a Release branch in source-code management (including the sources of documentation) so that future feature work can be committed and tested on the Develop branch without needing a full code freeze.
Regularly review the team's Definition of Done (either as part of Retrospective, or as a separate activity) to discover activities done for release that could (should) be part of a feature ticket.
Begin each story by having a Start-of-Story Conversation between the developer taking responsibility for the ticket and one or more other team members to identify what testing, documentation, policy update, approvals etc. need to take place as part of the story. This is also a good time to consider other impacts of the work, such as likely risk areas for regression.
Perhaps your policy updates and training can't actually happen until your product is released. But having prepared these as part of feature work, then the release activity is reduced to gathering together all the prepared pieces for the features actually included in the release and packaging them for delivery.
Don't expect the Definition of Done to be perfect after your first time updating it - my suggestion to regularly review is important. I'd suggest that you have this review after each of the next few releases; you'll find work that could have been done earlier, enabling you to release with less overhead (more accurately, with that overhead moved to be part of the feature work, getting you nearer to the ideal of release on demand).
Our Start of Story Conversation uses a template in our team wiki, that has a checklist of things we should examine to double-check that the story is Ready, and that all the risks and supporting work are considered before starting development. It normally takes 2-3 developers around five to ten minutes to walk through this and arrive at a shared understanding of what's included in a story, and what needs to be complete before it can move from one state to the next. Again, it's a living document, and the items in the checklist will be specific to your team and updated as you discover (in Retrospectives) oversights that could have been asked about before starting. (Actually, we choose one of several documents because we work on more than one product, and we have an additional one for non-product work such as infrastructure updates).
We still need "release sprints" in our team, but that's an improvement from taking two or more sprints to release, and we're still finding ways to move work to the left, so we haven't reached our limit as we aim to be able to release on demand.