Skip to main content

Policies

Policies are formal documents that describe your organization's security commitments. This guide explains how policies work in ForgeComply.

What Is a Policy?​

A policy is a documented statement of how your organization handles a specific security domain. Policies explain what you commit to doing.

Examples:

  • Access Control Policy
  • Incident Response Policy
  • Data Classification Policy
  • Acceptable Use Policy
  • Change Management Policy

Policies are distinct from:

  • Controls — Specific requirements you evaluate
  • Evidence — Proof that controls are operating

The relationship:

Policies describe intent → Controls verify implementation → Evidence proves operation

Why Policies Matter​

Auditor Expectations​

Auditors expect documented policies for major security domains. Undocumented practices are a red flag.

Organizational Clarity​

Policies ensure everyone knows the rules. They reduce ambiguity and support consistent behavior.

Compliance Requirements​

Both SOC 2 and ISO 27001 require documented policies covering key security areas.

Evidence Foundation​

Policies provide the baseline against which evidence is evaluated.

Policy Structure​

ForgeComply policies include:

  • Policy title
  • Version number
  • Effective date
  • Owner/approver
  • Review schedule

Purpose​

Why this policy exists.

Scope​

Who and what the policy applies to.

Policy Statements​

Specific commitments your organization makes.

Roles and Responsibilities​

Who is accountable for what.

Review and Updates​

How and when the policy is reviewed.

The Policies Page​

Navigate to Policies in the sidebar to manage your policies.

Policy List​

Each policy shows:

  • Policy name
  • Domain (security area)
  • Status (Draft / Approved)
  • Last updated
  • Linked controls count

Actions​

  • View/edit policy content
  • Approve policies
  • Download as document
  • Link to controls

Generating Policies​

ForgeComply generates policies based on your organization's profile and control responses.

How Generation Works​

  1. Organization profile — Company name, industry, size
  2. Control responses — What you've implemented
  3. Framework requirements — SOC 2 or ISO 27001 expectations
  4. Policy templates — Professional structure and language

ForgeComply combines these to produce relevant, specific policies.

When to Generate​

Generate policies:

  • After completing related controls
  • When starting a new security domain
  • When implementation significantly changes

Generation Does Not Mean Complete​

Generated policies are drafts. You should:

  • Review for accuracy
  • Adjust to match your actual practices
  • Get appropriate approval
  • Update the status to "Approved"

Policy Status​

Draft​

The policy has been generated but not approved.

  • Can be edited
  • Not considered final
  • Auditors may see as work-in-progress

Approved​

The policy has been reviewed and approved.

  • Represents official organizational commitment
  • Linked to controls for completeness
  • Ready for auditor review

Important: Only approve policies that accurately reflect your practices. Don't approve aspirational policies.

Policy Catalog​

ForgeComply includes 17 policy templates covering all security domains. Each policy maps to specific controls:

PolicyControls Covered
Information Security PolicyGV-01, GV-02, GV-04, GV-05, GV-06
Risk Assessment PolicyGV-03, RA-01, RA-02
Access Control PolicyAC-01, AC-02, AC-03, AC-04, AC-05
Change Management PolicyCM-01, CM-02, CM-03, CM-04
Incident Response PolicyIR-01, IR-02, IR-03
Data Protection PolicyDP-01, DP-02, DP-03, DP-04, DP-05
Vendor Management PolicyVM-01, VM-02, VM-03
Business Continuity PolicyBC-01, BC-02, BC-03
Security Awareness PolicySA-01, SA-02, SA-03
Logging & Monitoring PolicyLM-01, LM-02, LM-03, LM-04
Vulnerability Management PolicyVU-01, VU-02, VU-03
Acceptable Use PolicyHR-02, AM-02, AM-03
And 5 more...

Policies are domain-based, not control-based. One policy typically covers multiple related controls.

When you link a policy to a control, you're connecting that control to the relevant domain policy.

Editing Policies​

Making Changes​

  1. Click on any policy to view
  2. Edit content as needed
  3. Changes are saved automatically

What to Edit​

  • Company-specific details
  • Implementation specifics
  • Role names and titles
  • Frequency and timing details
  • Scope clarifications

What Not to Edit​

Avoid removing:

  • Core security commitments
  • Required elements for your framework
  • Structure that auditors expect

Approving Policies​

When to Approve​

Approve a policy when:

  • Content accurately reflects your practices
  • Appropriate stakeholder has reviewed
  • You're ready to commit to the statements

Who Should Approve​

Typically:

  • Security lead
  • CISO
  • CTO
  • Other designated authority

How to Approve​

  1. Review the policy content
  2. Click Approve on the policy card
  3. Status changes to "Approved"

Changing After Approval​

You can edit approved policies, but:

  • Consider version implications
  • Update effective date if significant changes
  • Re-approve if necessary

Policy Updates During Guided Setup​

If you're using Guided Setup and complete controls in a domain:

  1. Guided Setup may prompt policy generation
  2. Generate the policy for that domain
  3. Review and adjust as needed
  4. Continue with controls

You don't need to approve immediately — focus on getting through controls first, then return to finalize policies.

Linking Policies to Controls​

  • Demonstrates controls have documented backing
  • Shows organizational maturity
  • Required for control completeness

From a control:

  1. Open the control detail
  2. Find the Policy section
  3. Select the relevant policy

From a policy:

  1. Open the policy
  2. View linked controls
  3. Add additional control links if needed

Unlinked Controls​

Controls without linked policies show as incomplete. This affects control status.

Policy Best Practices​

Be Accurate​

Policies should reflect what you actually do, not what you wish you did.

Be Specific​

"Access reviews occur quarterly" is better than "Access is reviewed periodically."

Be Realistic​

Don't commit to things you can't sustain.

Review Regularly​

Policies should be reviewed annually at minimum.

Update When Things Change​

If implementation changes, update the policy.

Policies in Reports​

When you generate reports:

  • Approved policies are included in the Control Matrix
  • Policy coverage is summarized in the Audit Readiness Report
  • Draft policies may be noted as incomplete

Reports capture policy status at generation time.

Frequently Asked Questions​

Does AI write my policies?​

AI assists with generation based on your profile and responses. You review, edit, and approve. The final policy is yours.

Can auditors see draft policies?​

Auditors see what's in reports. Draft policies may appear as incomplete coverage.

What if I don't have a policy for something?​

Generate one, or acknowledge the gap. Don't fake it.

How often should policies be updated?​

At minimum annually, or when significant changes occur.

Can I import existing policies?​

Currently, policies are generated within ForgeComply. You can copy content from existing policies into the editor.

Next Steps​