Paldorin Digital — policy library
Policy Handbook for Paldorin Digital
This handbook defines what a policy is at Paldorin Digital, what it has to contain, and how it gets approved. It is the reference the rest of our documents point back to, so it stays deliberately short.
Two conventions apply throughout. A policy states principles, rules, and directions that guide decision-making; it is not a procedure manual. And every policy must say plainly what compliance requires. If a reader finishes a policy and cannot tell whether they are in scope, the policy has failed.
What counts as a policy
A policy is a written statement of principles, rules, and directions that guide decision-making. That definition is doing real work: it separates the document that says “we do not retain data beyond the stated period” from the procedure that explains which system deletes it and when.
Principle
Policies set the boundary. Procedures operate inside it. When we draft, we sort the two before writing a sentence, because mixing them is the most common reason a policy becomes unreadable.
Rule
Every policy names its compliance requirements in its own section, not in narrative. A reader arriving mid-task should find the rule in seconds, then decide whether they are in scope.
Direction
A document that only states intent is not a policy. Each one answers whom it applies to, what they must do or not do, and how that is verified.
Length is a compliance tool
Our default limit is four pages, excluding version history and approvals — because long policies get skimmed, and skimmed policies get misapplied.
If a draft runs past four pages, the fix is almost never smaller type. It is splitting the document, moving procedure to a separate file, or deleting the paragraph that restates something already covered elsewhere. Brevity here is a compliance tool, not an aesthetic preference.
The drafting template
Drafts start from the standard template rather than a blank page. It carries the required sections: scope, compliance requirements, related documents, review cycle, and administration block.
Writers sometimes resist templates as constraining. In practice the template removes the structural decisions that eat drafting time and lets the writer spend that effort on the one thing that matters, which is saying the rule clearly.
The template is maintained alongside the Documentation Style Guide, and changes to it follow the governance process rather than a writer’s preference.
Required sections
- Scope
- Compliance requirements
- Related documents
- Review cycle
- Administration block
Approval and sign-off
A policy is not in force until the formal approval process completes. That means a named owner, a review by the people affected by the policy, and a recorded sign-off before publication. Version 1.0 of anything should be traceable to a decision, not to whoever happened to publish it. If you are unsure whether a document you are following is approved, the administration block at the end of the page resolves it.
-
Named owner
One person is accountable for the document through drafting, review, and publication. Ownership does not transfer because the draft changed hands.
-
Review by those affected
The teams and roles the policy touches read the draft before it goes forward. Their comments are recorded alongside the version they reviewed.
-
Recorded sign-off
Approval is entered in the administration block with the date and the approver. Without that entry the document is a draft, whatever its version number says.
-
Publication
The approved version replaces the previous one in the policy library. Earlier versions stay archived so a reader can see what changed and when.
Scope statements earn their space
The scope section looks like boilerplate and is not. It names who the policy applies to, what it covers, and what it explicitly does not. That last part prevents most misapplication. A scope that only says who is included forces readers to guess about edge cases, and guesses become incidents. We write exclusions in the same sentence style as inclusions, not as an apologetic footnote.
In every scope section
- Who it applies to. Staff, contractors, vendors, or site visitors — named plainly.
- What it covers. The decisions and materials the policy governs.
- What it does not cover. The exclusions that keep edge cases out of the grey area.
Related documents, not repetition
Policies reference each other by title and section rather than copying text. When the Style Guide’s rule on date formatting changes, no other policy needs editing, because none of them restate it. This keeps the library consistent and keeps each document near its four-page limit. It also means readers sometimes need to follow one link to get the full picture. That is the trade we accept in exchange for a library that can actually stay current.
Review cycle and triggers
Every policy carries a scheduled review interval and a set of triggers that force an earlier one. Reviews do not require rewriting. Many end with a note that the document stands as written. What matters is that somebody looked, on a schedule, and that the look is recorded.
- A change in law or regulation that touches the policy’s subject.
- A change in how we operate that makes the current wording inaccurate.
- A documented failure of the policy in practice — something went wrong because the rule was unclear or unworkable.
What the handbook is not
Three boundaries worth stating up front, because each one protects a policy from being asked to do a job it was not written for.
It is not a legal contract, and it does not replace advice on a specific situation.
It is not a catalogue of every rule at Paldorin Digital. It is the standard that individual policies are held to.
If you need the actual rule about a topic, look for the policy itself. If you need to know whether that policy is well-formed, this handbook is the measure.
Writing rules this handbook assumes
The handbook does not restate grammar and formatting standards; those live in the Documentation Style Guide. What it does assume is that every policy will be written in plain language, in active voice, with sentence-case headings, and structured so a reader can scan it rather than read it linearly.
A policy that is accurate but hard to scan will be misquoted. Readability is part of accuracy.
Open the Documentation Style GuideQuestions we get while drafting
The three questions that come up most often from owners, reviewers, and readers of a policy in progress.
Does a policy need legal review before approval?
If it touches legal obligations, yes, as part of the formal approval process. The administration block records who signed off.
What happens if a policy exceeds four pages?
It gets split, trimmed, or has procedural detail moved to a separate document. The limit applies to the policy itself, not to its attachments.
Who decides when a policy is retired?
The named owner proposes retirement, and it follows the same approval path as a new policy. Retired policies are archived rather than deleted.
Find something in a policy you cannot read?
Tell us which policy, which section, and what you were trying to decide. Unclear scope and buried compliance requirements are the two things this handbook exists to catch, and reports from readers are how they get caught.