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 what you told it when you created the organization: your industry, your operating region, and the technology you work with. 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.

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 project are written against.

Alongside the policies sit your business goals, your brand and tone of voice, and 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 project’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.

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

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 project inherits the correction.