Virtual CISO · Policies and documentation
Policies written for how your organization works, and kept current
Most organizations that need a policy set already have one: bought, downloaded or inherited, describing a company that is not quite theirs, approved by nobody and read by no one. Replacing it is not a writing job. It is the job of knowing what you actually do, and writing that down in a form an auditor will accept.
One master document, the policies under it, and the records that prove it runs
Not a single enormous file, and not forty disconnected ones. Four layers, each with a distinct role that complements the others.
- 01
The master information security policy
Nine numbered sections built on the structure of ISO/IEC 27001:2022 — scope, the roles and who holds them, the risk approach, the controls, how the whole thing is reviewed. It is the document a regulator or a certification auditor asks for first, and the one everything else hangs from.
- 02
Domain policies
Access control, backup, supplier management, incident handling, remote work, asset management and the rest, one per domain. Each says what the organization requires, who it applies to, and which controls it satisfies — so it can be read on its own by the team that has to follow it.
- 03
Procedures and standard operating procedures
The step-by-step level: how a joiner is given access, how a backup restore is tested, how an incident is escalated and to whom. Written once and reused wherever the same step appears, so a change to the process is a change in one place.
- 04
Registers and records
The asset register, the supplier register, the risk register, the training records and the approval log. A policy that nobody can show is operating is a document; a policy with its records attached is evidence.
Written from your answers, not from a folder of templates
The raw material is the work already done: the assessment answers, the notes taken in the workshops, the tools you told us you run, the tasks that are open and the ones that are closed. A policy drafted from that describes an organization that exists. A policy drafted from a template describes a composite of everybody, which is why the first question an auditor asks about one is whether anybody follows it.
The policies we generate can carry footnotes naming the controls they satisfy, in each framework that asks for them — it is an option set when the document is produced, and we turn it on. That is what makes a document usable in an audit rather than merely present: the auditor reads a requirement, and the footnote says which paragraph of which policy answers it and which tasks implement it.
A policy whose status follows the work behind it
Each policy is tied to the tasks that implement it. While those tasks are open the policy shows as incomplete, and it says how incomplete — which is uncomfortable and correct. The alternative is the common one: a document set finished in March, approved in April, and describing an organization that stopped existing in June.
When the work changes, the affected documents are flagged rather than quietly left behind, and the review comes round on a date rather than when somebody remembers. Reviewing is the part every policy set promises in its own last section and almost none of them do.
The document your people read and the document your auditor reads
Drafting and translation happen in the same workflow rather than as a project afterwards, so the Hungarian, English and German versions of a policy stay the same policy. That matters more than it sounds: a translated policy set that drifted is two sets of requirements, and the one your staff follow is whichever is on the intranet.
The review is a human one. A translated clause that is grammatically perfect and legally wrong is worse than an awkward sentence, so the version that goes for approval has been read by somebody who knows both the language and the obligation.
Three things the portal refuses, and we would rather you knew now
These are not caveats added for safety. They are the reasons the output is worth signing.
- It does not invent a control. If a framework requires something the organization has not answered for, the draft leaves the gap visible instead of writing a plausible sentence over it.
- It does not invent a citation. A footnote pointing at a clause that does not say what the footnote claims is the single fastest way to lose an auditor, and it is unrecoverable once found.
- It does not declare you compliant, and neither do we. A document set is evidence put in front of somebody whose job is to decide — your certification body, your regulator, or the customer running the questionnaire.
Where only you can supply a fact — the approver, the document number, the date a committee met — the draft carries a marked placeholder rather than a guess. An unfilled placeholder is an obvious defect. A confident wrong date is not.
Who signs it, where it lives, and what you walk away with
A policy becomes a policy when somebody with the authority to carry it approves it, and the approval is recorded with a date and a version. Until then it is a draft, and your portal says so. Our work is to produce the document and to be the person who answers questions about it; the signature is yours, because the accountability is.
Everything is stored in your own document area, exports to DOCX for the review cycle your organization already runs, and is yours to take at any time and at no charge — during the engagement and on the day you leave. A policy set you cannot remove from a supplier’s system is a policy set you are renting.
Frequently asked questions
The questions we hear most often from security and IT leaders.
Something not covered here? Ask us directly
Yes, outright. Everything we draft for you is yours: it lives in your own document area, exports to DOCX whenever you want it, and you can take the whole set at any time and at no charge — during the engagement and on the day you decide to end it. There is no version of this where leaving costs you your policy set, because a document set you cannot remove from a supplier’s system is one you are renting rather than owning.
Yes, and where they are genuinely yours it is the better option — a policy your people already recognize has a far better chance of being followed than a new one. What we will tell you honestly is when it is not worth it. If what you have is a purchased template set that was never adapted, editing it costs more than starting from your own answers and produces a worse document, because the structure is built around somebody else’s organization. We will say which case you are in after reading them, not before.
Somebody in your organization with the authority to commit it — usually the management body, sometimes a delegated owner per domain. It cannot be us, and that is not a technicality: a policy is a statement of what your organization requires of its own people, and an external party cannot make that commitment on your behalf. We draft it, we answer questions about it, we sit in the approval meeting if that helps. The signature and the accountability stay with you.
Where this sits, and what comes next
Framework mapping
One control answered once, and counted against every framework that asks for it.
Ready to get started?
Partner with Spirity Enterprise to implement the right security and IT solutions for your organization.