Start a Security Policy From a Framework Template in Safeguard

To start a security policy from a framework template in Safeguard, open the framework on Compliance › Frameworks, go to its Policies tab, select New policy and choose Start from template. Edit the draft, fill in anything still in brackets, then choose Submit for review. A compliance reviewer approves one specific version; that version is then in force, with an effective date and a review date one year out.

That is the whole flow in the Compliance and GRC suite (GA). The rest of this post covers why auditors care about each step, what the templates give you and what they do not, how an approved policy stays in force while you edit the next version, and where an AI assistant helps without ever approving.

Key takeaways

• Compliance and GRC suite (GA). Policies live on Compliance › Policies and on each framework's Policies tab. Every framework in the library has policy templates to start from: a standard set adapted to that framework, plus framework-specific templates for many frameworks.
• Templates are drafts, not approvals. A template fills the editor. Nothing is in force until a compliance reviewer approves a version.
• One approved version at a time. Editing an approved policy creates a new version for review. The approved version stays in force until the new one is approved.
• Dates are built in. On approval the effective date defaults to the approval day and the next review to one year later. Recording the annual review moves the date on by a year without a new version.
• Lion (docs call it Lino), Safeguard's compliance and narrative model (GA), covers policy authoring. Safeguard's assistant and MCP clients such as Claude can draft and submit, but never approve.
• Two things share the word "policy". Compliance policies are written documents. Security policies, gates and guardrails (GA), including plain English policy creation (GA), are rules that evaluate scan results. This post is about the first kind.
• Policies back controls. An approved policy linked to a control is what a control's Policies tab shows as covering it. It shows the rule exists; it does not prove the control operates.
• Also mentioned: the Safeguard MCP server (GA) via Claude's connector directory, in-app agentic search (GA), the Safeguard CLI (GA) and desktop app.

What auditors expect from a written security policy

Almost every security framework starts with the same request: show me your policies. It is the first document request in most SOC 2 and ISO/IEC 27001 audits, and the one a first compliance hire is least ready for. The frameworks are specific about what makes a policy auditable rather than just written.

SOC 2: the Trust Services Criteria

A SOC 2 examination measures a service organisation's controls against the AICPA's Trust Services Criteria. Their Common Criteria cover deploying control activities through policies and procedures, and communicating responsibilities to the people who carry them out. In practice, an auditor wants a policy that says what is expected, evidence that management approved it, and evidence that it reached the people expected to follow it. For the full map of the criteria, see SOC 2 trust services criteria explained.

ISO/IEC 27001:2022: policy as a management system requirement

ISO/IEC 27001:2022 treats policy as part of the management system, not an optional extra. It expects top management to set an information security policy, and its Annex A controls expect topic-specific policies that management approves, that reach the people they affect, and that are reviewed at planned intervals or after significant change. Its rules on documented information cover review, approval and version control. ISO/IEC 27002:2022 gives guidance on the topic-specific policies an organisation typically has, such as access control and secure development. The short version: approved, versioned, communicated and reviewed on a schedule.

HIPAA: 45 CFR 164.316

The HIPAA Security Rule builds policy into its structure. Most of the administrative safeguards in 45 CFR 164.308 open with the same words. The security management process standard, for example, says to "implement policies and procedures to prevent, detect, contain, and correct security violations."

Section 164.316 then sets the rules for those policies:

• 164.316(a), policies and procedures. Implement reasonable and appropriate policies and procedures to comply with the Security Rule. You may change them at any time, provided the changes are documented and implemented in line with the rule.
• 164.316(b)(1), documentation. Maintain the policies and procedures in written form, which may be electronic, and keep a written record of any action, activity or assessment the rule requires.
• 164.316(b)(2)(i), time limit. Retain that documentation for 6 years from the date of its creation or the date when it last was in effect, whichever is later.
• 164.316(b)(2)(ii), availability. Make the documentation available to the people responsible for implementing the procedures it covers.
• 164.316(b)(2)(iii), updates. Review documentation periodically and update it as needed in response to environmental or operational changes.

The retention rule matters for versioning. "When it last was in effect" means you need to know which version was in force on which dates, and keep superseded versions, not just the current one.

NIST CSF 2.0 GV.PO and NIST SP 800-53 "-1" controls

NIST's Cybersecurity Framework 2.0 added the Govern function, and policy has its own category, GV.PO. GV.PO-01 says policy for managing cybersecurity risks is established based on organisational context, strategy and priorities, and is communicated and enforced. GV.PO-02 says that policy is reviewed, updated, communicated and enforced to reflect changes in requirements, threats, technology and mission.

NIST SP 800-53 Rev. 5 is more prescriptive. Every control family starts with a "-1" control, such as AC-1 for access control. AC-1 asks the organisation to develop, document and disseminate an access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination and compliance; to designate an official to manage it; and to review and update it at a defined frequency and after defined events. The discussion text includes a line every template user should read: "Simply restating controls does not constitute an organizational policy or procedure."

That sentence is the honest limit of any template library, including Safeguard's, and this post comes back to it.

What makes a policy auditable

Across those sources, the same attributes come up:

Safeguard's policy flow records the first six for you as part of how a policy moves from draft to approved. The last two need your attention, and the limits section below says why.

Compliance policies versus security policies and gates

Safeguard uses the word "policy" for two different objects, and mixing them up is the most common source of confusion for new users.

Compliance policies are the written documents this post is about: an Information Security Policy, an Access Control Policy, an Incident Response Policy. They live in the Compliance and GRC suite (GA), on Compliance › Policies and on each framework's Policies tab. They have an owner, a body of text, versions, an approval and a review date. A person reads them.

Security policies, gates and guardrails (GA) are rules the platform evaluates. Safeguard's docs describe policies that evaluate your SBOMs and generate findings (for example, no critical CVEs, or no components above a CVSS threshold), and gates that enforce those policies at checkpoints such as CI or release, with actions such as block, warn, notify or require approval. Plain English policy creation (GA) belongs here: you describe a rule in a sentence and Safeguard turns it into a policy that generates findings. A machine reads them.

The two do meet. A Vulnerability and Patch Management Policy might commit you to fixing critical vulnerabilities within a set number of days. A security policy and gate is one way to enforce that commitment in CI, and its findings and exposure windows are evidence that you meet it. For that side of the story, read plain English security policies to release gates in Safeguard.

What the template library covers

The standard set

Safeguard's docs say every framework in the library has policy templates to start from: a standard set, adapted to that framework. The standard set covers the topics most security frameworks ask about. It includes, among others:

• Information Security Policy
• Access Control Policy
• Acceptable Use Policy
• Data Protection and Privacy Policy
• Incident Response Policy
• Business Continuity and Disaster Recovery Policy
• Third-Party / Vendor Risk Management Policy
• Change Management Policy
• Vulnerability and Patch Management Policy
• Logging and Monitoring Policy
• Encryption and Cryptography Policy
• Risk Assessment and Management Policy
• Secure Software Development Policy
• Asset Management Policy
• Security Awareness and HR Security Policy
• Backup and Data Retention Policy
• AI and Responsible Use Policy

The subjects line up with the topic-specific policies ISO/IEC 27002 describes and the "-1" families in SP 800-53, so this set answers the first policy request in most audits.

When a framework-specific template replaces the standard one

For many frameworks, Safeguard has also written templates specifically for that framework. The docs give the rule: where a framework has its own template on the same subject, that one replaces the standard one. You do not see two Incident Response templates for one framework and have to guess which is right. You see the one written for that framework, with its terms and references, and the standard version fills any subject the framework-specific set does not cover.

Start from the framework your auditor will test against.

Templates carry their controls

A template is not only text. Each one is linked to the framework controls it is meant to support. That link shows up in two places in the app:

• On a framework's Policies tab, alongside the policies you already have.
• On a control's own page, where the Policies tab lists the policies that back that control and offers "Policy templates for this control" when nothing backs it yet.

The second route is often the faster one. If a readiness review shows a control with no policy behind it, open the control, look at its Policies tab and start from the template it suggests. The policy you create keeps the link to that control.

Placeholders and company details

Templates contain placeholders for things only you know: the company name, the policy owner, the system names. Fill every one before you submit. A policy approved with "[Company Name]" in it is a finding waiting to happen.

How many templates exist, and for which frameworks, depends on your library and plan. Your Safeguard plan decides which frameworks your organisation can choose from, and your administrator manages that list. This post does not quote counts.

Step by step: start a policy from a template, review and approve

The steps below follow Safeguard's docs for the framework and approvals flows, with the labels you see in the app. They assume the framework you need is switched on.

1. Switch on the framework, if it is not already. Open Compliance › Manage, then the Frameworks tab. Find the framework by region, country, industry or type, or search for it. Switch it on and select Save. It then appears on Compliance › Frameworks, Controls and Overview. National data-protection and cybersecurity laws start switched off, so check those first.

2. Open the framework. Go to Compliance › Frameworks and open the framework your auditor will test against, for example SOC 2 or ISO/IEC 27001.

3. Open its Policies tab. The tab lists the policies you already have for that framework and the templates available to it, with the controls each one supports.

4. Select New policy, then Start from template. The editor opens as a New Policy sheet. Pick a starter template from the list. The title, description and body fill in from the template.

5. Set the owner. Enter the owner, usually a role mailbox or the named person accountable for the policy. This is the "designated official" SP 800-53 AC-1 asks for and the accountable person ISO 27001 expects.

6. Edit the body. The body is markdown. Read it end to end and change it to describe what your company actually does: real system names, real roles, real timelines. Delete commitments you will not keep. Add the ones your auditor will look for that are specific to you. The section "Write the policy you will follow" below has a checklist.

7. Clear the placeholders. Search the text for anything still in brackets and fill every one.

8. Save draft, or Save and submit for review. Save draft keeps it as a draft for more work. Save and submit for review sends it to a compliance reviewer. You can also submit later from Compliance › Policies with Submit for review.

9. A compliance reviewer approves the version. The reviewer opens the policy, reads the text and approves that version. The app shows "Version 1 is approved and in force", with the effective date and the review due date. If the text needs work, the reviewer can return it to draft instead.

10. Link and check. Open one of the linked controls and confirm the policy now appears on its Policies tab as covering the control. If a readiness review flagged that control for a missing policy, it should now show a policy in force.

A short note on who can do what. The docs define a compliance reviewer as an administrator (Super Admin, Tenant Admin or Org Admin), a holder of the GRC role or a compliance admin, manager or reviewer role, or anyone granted a compliance review, approve, admin or manage permission. The Auditor role alone is not a reviewer. If you cannot see the option to use a template, your role may not allow edits; ask your Safeguard administrator. For the full approvals model across policies, evidence, exclusions, risks and crosswalks, see who approves what in Safeguard compliance.

Write the policy you will follow

A template gives you structure and the language auditors expect. It does not know your company, and this is where most of the real work sits.

What to change in every template

• Scope. Name the systems, environments and people the policy covers. "All production systems" is fine if you can list them when asked.
• Roles. Replace generic roles with the ones you have. If you have no CISO, do not leave "the CISO approves" in the text.
• Timelines. Every number in a policy is a commitment an auditor will test. If the template says critical vulnerabilities are fixed in 15 days and you fix them in 30, change the text or change your process before approval.
• Exceptions. Say who can approve an exception and how it is recorded. A policy with no exception path gets broken quietly.
• Tools. Name the systems that implement the policy, in general terms, so an auditor knows where to look for evidence.
• Review cadence. One year is the default in Safeguard. If a framework or customer contract asks for something shorter, write it in and plan for it.

A worked example: an Access Control Policy for a first SOC 2

The example below is illustrative. It shows the shape of the flow, not data from any customer.

A 40-person software company is preparing for its first SOC 2 Type I. Its readiness review shows several access controls with no policy behind them. The new compliance lead takes these steps:

Monday. She opens Compliance › Frameworks, then SOC 2, then the Policies tab. The Access Control Policy template is listed with the controls it supports. She selects New policy, Start from template, and picks it. Three placeholders are left: the owner, the identity provider and the review cadence for privileged access.

Monday afternoon. She sets the owner to the security lead's role mailbox. She pastes the draft into Claude, connected to Safeguard through Claude's connector directory, and asks for every statement an auditor could test. Claude lists eleven, including quarterly access reviews for production and offboarding within one business day. Nothing in Safeguard changes.

Tuesday. She checks the commitments with the engineering manager. Offboarding within one business day is true. Quarterly access reviews are not happening yet. She has two honest choices: change the policy to say what happens today, or start the reviews before the policy is approved. She edits the text to semi-annual reviews for now, with a note to tighten it next year, and clears the last placeholders. She chooses Save and submit for review.

Wednesday. The head of engineering, who holds a compliance reviewer role, reads the policy and approves version 1. The policy page shows that version 1 is approved and in force, effective that day, with a review due one year later. The access controls the template was linked to now show a policy in force on their Policies tab.

Six months later. The company starts quarterly access reviews and the compliance lead edits the policy to say so. The app saves version 2 for review. Until a reviewer approves version 2, version 1 stays in force.

What the auditor sees at fieldwork: a named owner, an approval with a date and a name for each version, the text of each version, an effective date and a review date, and the controls the policy backs. What the auditor still asks for: evidence that the access reviews actually ran.

Editing an approved policy: the approved version stays in force

This is the step auditors notice, and the one most document tools get wrong. In a shared drive or a wiki, editing a policy changes the live text at once. For the hours or weeks until someone re-approves it, staff are bound by text nobody approved, and the approval record points at text that no longer exists.

Safeguard separates the two. The docs put it plainly: editing an approved policy sends the new version to review, while the approved version stays in force. The editor says the same thing when you open an approved policy: saving changes creates a new version for review, and the approved version stays in force until the new one is approved.

A few consequences follow:

• An approval covers one version of the content. It is tied to the text the reviewer saw, not to the policy as an abstract object.
• Decisions are recorded. The docs say each decision is recorded with who made it, when and why.

This is also what makes the HIPAA retention rule workable. Section 164.316(b)(2)(i) counts 6 years from when a policy "last was in effect". With versions and approval dates recorded, you can answer which text was in force on a given day.

Only a compliance reviewer approves a policy. If the text needs work, the reviewer can return it to draft instead.

Effective date, next review date and the annual review

On approval, the docs say, the effective date defaults to the approval day and the next review to one year later. The policy then shows its effective date and when its review is due.

The annual review has its own action, Record annual review. It is for the common case where a reviewer reads the policy, checks it against how the company works today, and decides nothing needs to change. Recording the review moves the review date on by a year without creating a new version.

That distinction matters to an auditor. ISO/IEC 27001, CSF GV.PO-02, HIPAA 164.316(b)(2)(iii) and SP 800-53 AC-1 c all ask for review at planned intervals. An auditor wants to see that the review happened. A new version with no changes, approved only to reset a date, muddles the record. A recorded review with no new version says exactly what happened: someone looked, and the text still holds.

When a review does find something to change, edit the policy instead. The edit goes to review as a new version, and its approval resets the effective date and the review clock.

Review after events too. AC-1 c and GV.PO-02 both expect a review after significant changes, such as a new framework, an incident or a reorganisation. Treat the annual date as the latest point a review happens, not the only one.

Where AI drafting helps and where a person must decide

Safeguard's offering lists Lion, which the docs call Lino, as its compliance and narrative model (GA), and policy authoring is one of the jobs it covers, along with regulatory mapping, evidence quality checks and audit-grade summaries. Separately, you can bring Safeguard into Claude through the Safeguard MCP server (GA), added from Claude's connector directory, where Safeguard is listed as a community connector.

Where an assistant genuinely helps with policies:

• Explaining a template. Ask what each section commits you to, in plain language, before you approve it.
• Listing testable statements. Ask for every sentence an auditor could test, so you can check each against reality.
• Finding gaps. Ask which of a framework's policy-related controls have no policy in force, where the tools your tenant has enabled return that data.

Where a person must decide, every time:

• Approval. Safeguard's docs state the rule directly: a change made through Safeguard's AI assistant or an MCP client can draft and submit, but never accept, approve, launch or acknowledge, whoever is signed in behind it. Even a write you confirm cannot approve anything.
• Commitments. Whether your company will actually fix critical vulnerabilities in 15 days is a business decision. A model can tell you the template says 15; it cannot tell you whether your on-call team can meet it.
• Truth. Whether a sentence in the policy describes what really happens.

Writes from an assistant also wait for you. The docs say an MCP client runs a write only after you confirm it in that client, and in Griffin AI Search inside the app (in-app agentic search, GA) every write shows a Confirm or Cancel card. Which write tools appear at all depends on your tenant's plan and your administrator's settings, so in many tenants the assistant only reads and drafts text in the chat for you to paste.

There are two good reasons for this line, and OWASP's Top 10 for LLM applications names both. LLM06:2025, Excessive Agency, covers damaging actions taken on unexpected, ambiguous or manipulated model output; an approval is exactly that kind of high-impact action. LLM09:2025, Misinformation, covers model output that looks credible but is wrong, and the overreliance that lets it through. A policy is the place where plausible but wrong text does the most damage, because it becomes a commitment. Keep the assistant in the drafting seat and the person in the approving one.

How policies back controls as evidence

A policy matters to your readiness because it backs controls. Safeguard's framework docs describe how a framework is covered: scan requirements checked on each product scan, and for many frameworks, more catalogue controls that you evidence with automated tests, uploaded evidence, policies and attestations. Some requirements need evidence a scan cannot see, and the docs give a policy as the first example. Those pass when a person attests them with evidence.

In the app, the link works like this:

1. The template sets the link. A policy started from a template keeps the controls that template was written for.
2. Approval makes it count. When a version is approved and in force, the control's Policies tab shows the policy covering it. A draft or a submitted policy does not. A readiness score is Safeguard's assessment of what it can see. It is not an audit opinion or a certification.

A policy shows design, not operation

This is the point SP 800-53 makes when it says restating controls is not a policy, and it cuts both ways. A policy that says "access is reviewed quarterly" is evidence that the company decided to review access quarterly. It is not evidence that anyone did. A SOC 2 Type II examination tests whether controls operated over a period, and for that the auditor wants the review records, the tickets, the test results.

So pair every approved policy with the evidence that it runs:

• An Access Control Policy pairs with access review records and identity provider configuration tests.
• A Vulnerability and Patch Management Policy pairs with scan results, finding exposure windows and remediation records.
• A Change Management Policy pairs with pull request review settings and deployment records.
• An Incident Response Policy pairs with incident records and tabletop exercise notes.

Safeguard's automated tests and evidence flows cover the second half; see continuous compliance in Safeguard for how tests, evidence and controls fit together.

Decision table: requirement, what Safeguard does, what you still own

What Safeguard does not do

• It does not write your policy for you. Templates are starting points written to match common framework language. They are not legal advice and they do not know your systems, your people or your timelines. NIST's line applies: restating controls is not a policy. You make the text true.
• It does not approve anything on its own. No template, model, assistant or MCP client approves a policy. A compliance reviewer does. The Auditor role cannot either, by design.
• It does not prove a control operates. An approved policy backs a control's design. Operating effectiveness needs evidence: test results, records, tickets. Policy text alone will not carry a SOC 2 Type II or an ISO 27001 surveillance audit.
• It does not issue certificates or audit opinions. Choosing a framework and approving its policies does not certify compliance. An accredited auditor or certification body issues any report or certificate. A readiness score is not an audit opinion.
• It does not guarantee your retention period. HIPAA asks for 6 years from when a policy was last in effect. Safeguard keeps versions and approval records; confirm with Safeguard how long your tenant's data is retained, and export what you must keep if your retention duty outlasts your subscription.
• It does not replace communication and training. Approving a policy does not tell staff about it. How you communicate it, train on it and record acknowledgement is your process to run.
• It does not decide which policies you need. The library lists what is available for a framework. Your scope, your auditor and your customers' contracts decide which ones you write first.

Common mistakes

Approving templates unchanged. The fastest way to fail a policy review is to approve text that describes a company you are not. Auditors read policies, then test the statements. Every unchanged commitment is a test you may fail.

Approving everything at once. Every approved policy is a promise you will be tested on. A five-person company that approves a physical security policy describing badge readers it does not have has created findings, not removed them. Approve what you can stand behind and grow the set as controls become real.

Editing the live text somewhere else. Teams keep a copy in a wiki, edit it there, and forget the approved version in Safeguard. Then the record and the practice drift apart. Make Safeguard the place where the policy text lives and is approved.

Confusing compliance policies with security policies and gates. A plain English rule that blocks critical CVEs in CI is not your Vulnerability and Patch Management Policy, and the written policy does not block anything. You need both, and they answer different audit questions.

Leaving placeholders. "[Company Name]", "[System]" and "[Owner]" in an approved policy is an easy finding. Search for brackets before you submit.

Re-approving to reset a date. If nothing changed, record the annual review. A new version with no text changes muddles the record.

Letting an assistant's draft become the commitment. An AI-drafted timeline or role is a suggestion. Check every testable sentence with the person who runs the process before submitting.

Choosing reviewers by convenience. The person who approves a policy should have authority over what it commits the company to. An auditor will ask whether they did.

FAQ

How do I create a security policy from a template in Safeguard?

Open the framework on Compliance › Frameworks, go to its Policies tab, select New policy and choose Start from template. Pick a template, set the owner, edit the body, clear the placeholders, then Save and submit for review. A compliance reviewer approves the version.

Which policy templates does Safeguard include?

Every framework has a standard set adapted to it, covering topics such as information security, access control, acceptable use, incident response, change management, vulnerability and patch management, encryption, secure development, vendor risk, business continuity and AI and responsible use. Many frameworks also have templates written specifically for them, which replace the standard template on the same subject.

Are Safeguard's policy templates ready to approve as they are?

No. They are starting points, not legal advice. Change scope, roles, timelines, exceptions and tools to match what your company does, and fill every placeholder, before you submit for review.

Who can approve a compliance policy in Safeguard?

A compliance reviewer: an administrator (Super Admin, Tenant Admin or Org Admin), a holder of the GRC role or a compliance admin, manager or reviewer role, or anyone with a compliance review, approve, admin or manage permission. The Auditor role alone cannot approve, and neither can an AI assistant or MCP client.

What happens when I edit an approved policy?

Safeguard saves the edit as a new version and sends it to review. The approved version stays in force until a reviewer approves the new one.

How does the annual policy review work in Safeguard?

On approval, the next review defaults to one year later. When a reviewer reads the policy and decides nothing needs to change, they choose Record annual review, which moves the date on by a year without a new version. If something does need to change, edit the policy and the new version goes to review.

Can Claude write or approve my policies through the Safeguard connector?

Claude, added from Claude's connector directory, can help draft and explain policy text. Depending on the tools your tenant enables, it may submit with your confirmation. It can never approve a policy, whoever is signed in.

Does an approved policy make a control pass?

An approved policy linked to a control backs that control and shows on its Policies tab. It shows the control is designed and documented. Auditors still want evidence that the control operates, such as test results or review records.

Does choosing a framework and approving its policies make us compliant?

No. Safeguard helps you prepare. Choosing a framework does not certify compliance, and a readiness score is not an audit opinion. An accredited auditor or certification body issues any report or certificate.

Fewer exceptions to write into the policy

A Vulnerability and Patch Management Policy is one of the first templates most teams approve, and its timelines are the commitments auditors test hardest. The block below is how Safeguard helps you meet those timelines in practice, including when upstream has not shipped a fix yet.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows Claude being connected to Safeguard with an OAuth sign-in and choosing which tools Claude may use. That choice is the same boundary this post describes: the assistant works within the tools your tenant grants, it can help draft and explain a policy, and it cannot approve one. In practice, add Safeguard from Claude's connector directory rather than setting up a custom connection.

Click through it at your own pace, or open it full screen.

The second demo is a real session in the Safeguard desktop app. A Safeguard CLI (GA) session appears in the app's conversation list, the app asks which computer and folder to use, and the person approves or denies the commands and file edits it proposes until the change is done and tests pass. It is a code change rather than a policy, but it shows the same principle the policy flow enforces: the agent proposes, and a named person decides.

Click through it at your own pace, or open it full screen.

To try the compliance suite yourself, get the apps at safeguard.sh/download and read the setup guides at docs.safeguard.sh.

Quick check

Sources

• Safeguard docs: Compliance frameworks
• Safeguard docs: Approvals
• Safeguard docs: Requests and approvals
• Safeguard docs: Policies and Gates
• Safeguard docs: Compliance
• Safeguard docs: Claude
• Safeguard docs home
• Safeguard download page
• NIST CSWP 29: The NIST Cybersecurity Framework (CSF) 2.0
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations
• 45 CFR 164.316: Policies and procedures and documentation requirements (LII)
• 45 CFR 164.308: Administrative safeguards (LII)
• 45 CFR 164.530: Administrative requirements (LII)
• OWASP GenAI Security Project: LLM06:2025 Excessive Agency
• OWASP GenAI Security Project: LLM09:2025 Misinformation

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.