Security Policy Generator

Free Security Policy Generator for SOC 2, HIPAA and ISO 27001

Auditors ask for written policies before they ask for anything else, and most organisations discover this about four weeks too late. This security policy generator produces six of the documents that framework assessments consistently require — Acceptable Use, Password, Incident Response, Access Control, Remote Work Security, and Data Classification — tailored to your organisation’s name, industry, size, region and the compliance frameworks you are working toward. You answer a short wizard, review the output, and download it as Markdown, plain text or PDF.

The generated documents are drafts written to be edited, not boilerplate to be signed unread. They are structured the way assessors expect — purpose, scope, policy statement, enforcement, exceptions, review schedule — and the technical parameters are yours to set rather than ours to assume.

The Six Policies It Generates

How to Use the Generator

1. Enter organisation details. Legal name, industry (healthcare, finance, legal, technology, retail, education, government, manufacturing or other), headcount band and effective date. Industry and size shape the language and the default expectations — a 1,000-person manufacturer and a 20-person clinic get different scoping paragraphs.
2. Set your compliance context. Select the frameworks that apply — SOC 2, HIPAA, PCI-DSS, ISO 27001, NIST CSF, GDPR, or none — and the regions you operate in (United States, EU, UK, Canada, Australia, or global). This drives the compliance references embedded in each document.
3. Choose which policies to generate. Pick one or all six. Generating everything at once produces a single combined document you can split later.
4. Tune the technical parameters. This is the step that separates a usable policy from generic filler. Set minimum password length, which character classes are required, rotation interval, password history depth and whether MFA is mandatory. Set the breach notification window in hours, your security team address and the title of the incident commander. Set the access review interval in days and whether privileged access needs explicit approval. Set the classification levels you actually use.
5. Review, then edit. Toggle between rendered rich text and raw Markdown. Copy to the clipboard, or export as PDF, Markdown or plain text.
6. Get it approved and communicated. A policy nobody signed is evidence of nothing. Route it through whoever owns approval, record the date, and collect workforce acknowledgement — that acknowledgement record is what the auditor samples.

Getting the Password Parameters Right

The password policy is where most organisations copy advice that is a decade out of date, so it is worth setting deliberately. Current authoritative guidance has moved a long way from the old “eight characters, four character classes, change every 90 days” formula.

NIST SP 800-63B, in its current revision, is explicit. Verifiers shall require passwords used as a single authentication factor to be a minimum of 15 characters, and passwords used only as part of multi-factor authentication a minimum of 8. They should permit at least 64 characters. They shall not impose composition rules requiring mixtures of character types. They shall not require periodic password changes, but shall force a change on evidence of compromise. And on establishment or change, verifiers shall compare the candidate password against a blocklist of known common, expected or compromised passwords. The reasoning is behavioural: composition rules and forced rotation push users toward predictable transformations that weaken rather than strengthen the resulting passwords.

PCI-DSS v4.0 takes a different line, and if you are in scope it wins for the cardholder data environment. Requirement 8.3.6 sets a minimum of 12 characters containing both numeric and alphabetic characters. Requirement 8.3.9 requires change at least every 90 days where a password is the only authentication factor, unless the security posture of accounts is dynamically analysed with real-time access decisions.

The practical resolution: mandate MFA everywhere, set length at 15 or higher, drop composition rules, drop rotation, add breach-corpus blocklisting — and carve out a documented exception for any in-scope PCI system that still relies on a password alone. Set those values in the wizard and the generated policy will say what you actually intend to enforce.

Getting the Incident Response Parameters Right

The breach notification window is the field people leave at its default and later regret, because the correct value is not a preference — it is dictated by whichever regime binds you, and by the fastest one if several do.

• GDPR Article 33 — notify the supervisory authority without undue delay and, where feasible, no later than 72 hours after becoming aware of a personal data breach, unless it is unlikely to result in a risk to rights and freedoms. Article 34 adds notification to affected individuals without undue delay where the risk is high. A processor must notify its controller without undue delay under Article 33(2).
• HIPAA — notify affected individuals without unreasonable delay and no later than 60 calendar days from discovery (45 CFR 164.404); notify HHS contemporaneously for breaches affecting 500 or more individuals, and via the annual log within 60 days of year-end below that threshold (45 CFR 164.408). Business associates notify the covered entity within 60 days of discovery (45 CFR 164.410).
• Contractual and sectoral obligations — customer agreements frequently impose 24 or 48 hours, and various sector regulators impose their own windows. Your internal escalation deadline should be shorter than the shortest external one, because the external clock includes the time you spend deciding.

Set the field to your internal escalation target, then make sure the policy names the person who decides whether an incident is a reportable breach. Plans fail at that decision far more often than at the technical response.

What a Generated Policy Does Not Give You

Three things, and being clear about them saves an unpleasant conversation with an assessor:

• It is not legal advice and it does not make you compliant. A document is a control artefact, not a control. Assessors test whether the policy is approved, communicated, and operating — they will ask for access review records, training acknowledgements and incident tickets, not just the PDF.
• It has not been reviewed against your obligations. Sector-specific rules, state privacy laws, employment law constraints on monitoring, and your own customer contracts can all change what a policy must say. Have counsel or your compliance lead review before adoption.
• It goes stale. Frameworks expect periodic review. Put the review date in the document, and honour it.

Frequently Asked Questions

Are the generated policies free to use commercially?

Yes. Generate, edit and adopt them inside your organisation at no cost, with no account required. They are drafts intended for you to modify.

Will these pass a SOC 2 audit?

Policies alone never pass an audit. A SOC 2 examination tests whether controls were designed appropriately and, for Type II, operated effectively over a period. Written policies satisfy part of the design question — particularly under CC1 and CC2 — but the evidence of operation is what consumes the fieldwork. Use these to close the documentation gap, then start generating the evidence trail.

Does the wizard produce policies that conflict with each other?

The parameters are shared across documents, so the password length in the password policy matches what the access control policy references. If you generate policies in separate sessions with different settings, reconcile them before adoption — conflicting internal policies are an audit finding in themselves.

Should I really stop expiring passwords?

If MFA is enforced and you are not bound by PCI-DSS for that system, current NIST guidance says yes: do not require periodic change, but force a change on evidence of compromise. Many organisations keep a long rotation interval for legacy systems that cannot support MFA. Document the reasoning either way — an assessor accepts a justified deviation far more readily than an unexplained one.

Is my organisation’s information sent to a server?

No. The wizard and the document generation run in your browser. Nothing you type is transmitted to us for storage, and exports are produced locally in the browser.

What format should I keep the master copy in?

Markdown, in version control, with PDF generated for distribution. That gives you a diffable history of what changed and when — which is exactly the question an assessor asks when a policy has been revised mid-audit-period.

Do I need all six policies?

Most frameworks expect all six in some form, but sequence matters more than completeness on day one. Acceptable Use and Password are the fastest to adopt; Incident Response is the one most likely to be tested in anger; Data Classification is the one that unlocks meaningful handling rules everywhere else.

What should I build next?

The data classification policy in this generator is deliberately short; if you need per-level handling rules for storage, transmission, access, disposal and labelling, build it properly with the data classification policy architect. For the operational side of incident response, the incident response playbook generator produces the step-by-step runbook the policy points to, and the SOC 2 gap analysis shows which controls still need evidence. To sanity-check the password parameters you chose, run a sample through the secure password generator.