Policies

Policies are your organization’s rules, written down in a form agents read before they produce anything.

This is the part of Taiga that makes generated work compliant by construction rather than compliant after a review caught something. A threat model written against your actual security policy is a different document from one written against a generic template.

Where they come from

You do not start from a blank page.

Taiga generates a baseline set from four answers about your organization: your industry, your country, and the technology and clouds you build on. The result is tailored rather than generic, and fully editable.

Then it asks you to confirm them. That prompt is doing real work, and it is worth answering properly rather than dismissing: everything generated from here is measured against these documents, so a policy nobody read is a standard nobody chose.

What the set covers

Nine policies, spanning the areas an enterprise is normally asked about:

Policy	Covers
Security & Access Policy	Authentication, authorization, and who can reach what.
Data & Privacy Policy	Classifying personal and sensitive data, keeping only what you need, and meeting obligations such as GDPR.
Risk Management	How you assess threats, what level of risk you accept, and what gets escalated.
Development Lifecycle	Review, testing, security scanning, and how releases ship.
Operations & Continuity	Observability, incident response, backups, and reversible change.
Architecture Standards	Approved stacks, API and data conventions, and patterns for scale and isolation.
Software Supply Chain Security	What you depend on and how you verify it.
Cloud Governance & Cost	Account guardrails, naming and tagging, approved services, and cost.
Third-Party & AI Policy	Third-party services and AI use.

These are not summaries with a heading each. Each policy arrives as concrete controls, each with an identifier and its rationale, which is what lets a generated document cite the exact control it satisfies and lets an auditor follow the reference back.

The first three do the most visible work: they are what the threat model, the data protection impact assessment and the risk register on every product are written against.

Complete as governance, generic where they should be

The generated policies are written the way good policy is written: obligations that hold everywhere, stated without the decisions only your team can make. They require consistent error formats, because naming one would be wrong for half the organizations reading it; established style guides, because yours are yours; coverage thresholds defined per product, because a universal number would be arbitrary.

Nothing is missing there. But where a control leaves a value open and you have a specific answer, your instructions are where it goes. A generated document that seems generic where you expected your conventions is usually asking for an instruction, not a policy edit.

Alongside the policies sit your design standards, which are governance of a different kind: they constrain what gets built rather than how it is secured.

Who can change them

Editing and publishing a policy is an administrator action. Everyone else can read them.

That is the split that makes a policy a policy: if the people whose work is measured against a rule can quietly change the rule, it is a preference. What members can write is knowledge and their product’s own instructions.

Versions and publishing

Policies are versioned and have a draft state, and the distinction matters more here than elsewhere.

A published policy is what agents work against. An edited draft changes nothing until you publish it, and every published version is kept as a snapshot you can point at later.

The draft is shared, not yours. There is one per policy for the whole organization, so two administrators editing the same policy are editing the same draft rather than each keeping a private copy. Worth knowing before you leave one open for a week.

That history is the useful part under audit. “What was our data policy when this product was assessed” has an answer.

Not every control reaches every product

Your policies hold everything your organization is subject to. A given product is generated against the part of that which applies to it: where a control belongs to an industry the product itself does not touch, it is left out rather than padding the work with obligations that do not apply.

This is why a product’s security documents can be shorter than your policy set without anything having been dropped. The relevance is judged from the product’s own documents, not from your settings, which is another reason a vague specification costs you later.

Updating one from a document you already have

Policies rarely start life in Taiga. If you have the real thing as a PDF or a spreadsheet, you can point a policy at it: upload the source, write a short instruction, and Taiga proposes targeted section updates.

You review the diff and apply only what you want, and it tells you which sections it considered and left alone. Nothing is replaced wholesale.

Keeping them honest

The failure mode is not writing a bad policy. It is writing a good one and letting it go stale while everything downstream keeps citing it.

Two habits worth having:

• Revisit after a real change. A new region, a new class of data, a new cloud provider. Each one dates a policy that still reads as current.
• Fix the policy, not the document. When a generated threat model gets something wrong about your security posture, the threat model is a symptom. Correct the policy and every future product inherits the correction.