Wiki Software for Insurance Companies: Compliance and Documentation
Learn what wiki software insurance companies need to meet state data security rules and keep documentation secure.
Imagine an underwriting team at a mid-sized insurer that keeps its rules for tricky applications in the company wiki. It starts out pretty simple. Someone writes up how to handle a case that doesn't fit the usual criteria, and it saves the team a dozen emails a week.
Two years later, those pages are full of examples. That's what made them useful. One walks through a business property application that was turned down, names the applicant, and explains exactly why. Another lists three customers who were written with modified conditions, with enough detail to work out who they are.
Nobody ever flagged the wiki as a system holding customer information. It was a productivity tool. IT set it up, the team started using it, and it never came up in a security review.
Then someone asks where the underwriting guidelines are kept, who can change them, and which servers the pages sit on. The team can answer the first question. The other two take a while.
What Insurance Teams Put in a Wiki
Before getting into the rules, it's important to be clear about what's in these systems. Insurance documentation splits into two layers, and they carry different kinds of information.
- The Operational Layer
This is the material that makes the day work:
- Agency SOPs and internal process guides
- Appetite guides, which set out which types of risk get written and which get turned away
- Submission checklists, quoting workflows, and system how-tos
- Onboarding material for new producers and adjusters
- Meeting notes, project pages, team reference material
None of it is especially sensitive on its own. It's the stuff you'd happily walk a new hire through on their first morning.
- The Layer That Carries Regulated Content
This is different:
- Underwriting guidelines, meaning the rules for what you'll cover and on what terms, especially the parts covering unusual cases
- Claims handling procedures and the rules for when a claim gets escalated
- Complaint handling procedures and their outcomes
- Rate and form filing documentation, meaning the paperwork behind the prices and policy wordings you file with the state
- Producer licensing and appointment records, covering which agents are licensed to sell for you
These pages tend to reference specific people, policies, and decisions. That's what makes them sensitive.
How Sensitive Information Gets into an Insurance Wiki
Almost nobody sets out to put regulated content in the wiki. It comes in by accident, and it always happens the same way.
Someone writes a procedure. The procedure is abstract, so it's hard to follow. A colleague adds a real example to make it clearer, and the example carries a name, a policy number, or a claim reference. It works, so people keep doing it. Six months on, half the pages in that space describe actual customers.
You end up with a system that started as general documentation and quietly turned into something else. If you've ever built out a wiki from scratch, you'll recognize the pattern. It's one of the reasons how you structure internal documentation matters more than it looks like it should at the start.
The Rules That Reach Your Documentation System
Insurance is regulated at the state level, and the rules follow the licensee rather than the tool.
- State Insurance Data Security Law
The NAIC Insurance Data Security Model Law, adopted in 2017, sets out what a licensee has to do about data security. It requires you to build and maintain a written information security program based on your own risk assessment, name someone responsible for it, and manage the third parties who touch your information. NAIC counted 28 jurisdictions as having implemented it as of August 2025, each with their own version, so the text that binds you is your state's statute rather than the model itself.
What matters here is how the law decides what's covered. There's no list of approved tools, and no type of software that sits outside it. The law follows the information. So if your wiki holds nonpublic information, it counts as one of the systems your security program has to cover, the same as your policy administration system or your email.
The model also defines a third-party service provider as any outside company, other than another licensed insurance business, that you contract with and that stores your nonpublic information or is allowed to look at it through the service it provides.
That sounds like it means claims administrators and IT contractors, and it does. It also means software.
- New York's Part 500
New York's rules matter even if you're licensed elsewhere. If you write any business in the state, you hold a New York license, and the regulation applies wherever your head office is. Even if you don't, New York's rules are the stricter set, so meeting them means meeting the model law too. The state's cybersecurity regulation, 23 NYCRR Part 500, applies to anyone holding a license under the Insurance Law, and it says being regulated by another agency doesn't get you out of it.
Section 500.11 is the one that matters here. It requires written policies covering the security of information systems and nonpublic information that a third-party service provider can reach or holds on your behalf. Those policies have to address how you identify and assess those providers, the minimum security practices they need to meet before you'll do business with them, the due diligence you use to check those practices are adequate, and how often you reassess them. They also have to cover the contract terms, including how the provider handles access controls and encryption, and what notice you get if something happens to your information while they're holding it.
- Health Plans Have a Second Set of Rules
If you're a health plan rather than a property and casualty carrier, you're also a covered entity under federal health privacy rules, and those bring their own requirements on top of everything here. That's a bigger topic than this post can carry, so we've covered it separately in our guide to HIPAA-compliant wiki documentation.
Your Wiki Vendor Is a Third-Party Service Provider
Put a hosted wiki holding underwriting notes and claims procedures against that definition and it fits: the vendor isn't licensed by your insurance department, you have a contract with them, and their service stores the information.
What That Classification Brings with It
Once a vendor is in scope, you owe a set of things:
- Identifying them as a provider and assessing the risk they represent
- Setting the minimum security practices they need to meet
- Doing due diligence to check those practices are adequate rather than just advertised
- Reassessing them periodically as the relationship continues
- Getting contract terms in place covering security obligations and incident notification
None of that is unreasonable. It's the same discipline you'd apply to any vendor holding customer data. The problem is that a wiki rarely gets treated as one.
Why Standard Subscription Terms Rarely Fit
Most cloud wiki products are sold on a self-service subscription. You put in a card, you get an account, and the terms are whatever's on the signup page.
That model works fine for a design tool. But it works less well when you need documented security commitments, incident notification timelines, and audit rights, because the vendor usually isn't set up to negotiate any of it with an individual customer.
The gap only becomes a problem when somebody asks you for the vendor assessment and there isn't one, and by then the wiki has three years of content in it.
What Happens When Someone Asks
Sooner or later somebody asks where your underwriting guidelines are maintained and who can change them. If the wiki sits on your own infrastructure, that's a straightforward answer with your own access records behind it. If it sits with a vendor, the answer involves explaining the vendor, their controls, and your assessment of them.
The wider version of this problem shows up across regulated industries, and we've written about how it plays out in financial services documentation.
Self-Hosted vs Cloud for Insurance Documentation
Self-hosting isn't automatically the right answer, and it isn't automatically more secure. It just changes what you're responsible for. These are the points to consider if you're thinking of self-hosting:
- Data never leaves infrastructure you control: There's no vendor holding it, which is what removes the wiki from the third-party service provider question entirely.
- You define your own compliance posture (access controls, encryption, retention) instead of inheriting a vendor's: If your state requires a specific retention period, you set it. You don't check whether a vendor supports it.
- Hosting, backups, upgrades, and security patching become your IT team's responsibility: If you don't have someone who can maintain a server, self-hosting will create problems rather than solve them.
If you're still weighing your options, our buyer's checklist for wiki tools walks through the rest of the criteria, and you can see how Docmost compares to Confluence if you're migrating from something you already have.
How to Set Up an Insurance Wiki
That's the legal side and the documentation it reaches. Next is organizing it so the restricted material stays restricted.
- Separate Spaces, Not Separate Page Titles
Restricted content needs different permissions, not a naming pattern. Calling a page "CONFIDENTIAL Underwriting Guidelines" doesn't restrict anything. A workable starting set of spaces looks like this:
- General operations open to everyone, holding SOPs and reference material
- Department spaces where the team writes and others read
- Underwriting restricted to underwriting and management
- Claims restricted to the claims function
- Compliance restricted to compliance and legal
Set the permissions before anyone starts writing. Moving content between spaces after the fact is slow and easy to get wrong.
- Connect It to the Identity System You Already Run
Wire the wiki into your SSO or directory rather than managing a separate user list. New teammates get access through the process you already have, anyone leaving loses it the same day they go, and your multi-factor rules apply without anyone configuring them twice.
- Retention
Work out how long you need to keep each type of record, then set the space to the longest period that applies to anything in it. Your state's insurance statute sets most of those periods, and if federal health privacy rules cover you too, follow whichever one is longer. The exact numbers change from state to state and from one record type to another, so this is a question for your compliance team rather than one we can answer here.
- Version History
Every change needs to be attributable and timestamped, and that record needs to survive. If someone rewrites an underwriting guideline, you want to know who did it, when, and what it said before. That's the difference between being able to answer a question about a guideline change and having to guess.
Using Docmost as Your Insurance Wiki
By using Docmost for your insurance documentation, you:
- Keep every page on servers you own, so no outside company is holding your nonpublic information
- Set permissions space by space, so underwriting and claims content stays with the people who need it
- Connect it to the identity system you already run, so new teammates and those leaving move through your existing process
- Get a full version history on every page, so any change to a guideline is attributable and reversible
- Control encryption, backups, and how long data is kept through your own infrastructure, rather than working to a vendor's defaults
Docmost is open source, and that matters here because you can read the code, host it wherever your infrastructure policy says data has to sit, and you're not depending on a vendor's plans to keep meeting a regulator's expectations.
Run Docmost on your own infrastructure and there's no third-party service provider in the picture, so there's no assessment to produce, no minimum practices to negotiate, and no reassessment schedule to keep.
The wiki sits inside your security program the same way your other internal systems do.
Frequently Asked Questions
- Does state insurance data security law apply to an internal wiki?
Yes, if the wiki holds nonpublic information. The rules cover information systems that hold covered data, and they don't carve out tools people think of as productivity software. What matters is what's in it, not what it's called.
- Is a cloud wiki vendor a third-party service provider?
Yes, if they hold or can reach nonpublic information through the service they provide you. That's the definition, and a hosted wiki holding underwriting or claims content sits squarely inside it.
- Do these rules apply to agencies and brokers, or only to carriers?
Both. The model law applies to entities licensed by the state insurance department, which covers agencies, agents, brokers, and adjusters alongside carriers. If you hold a license, you're in scope.
- Are small agencies exempt?
Sometimes, and only partly. The NAIC model exempts licensees with fewer than 10 employees, those already complying with federal health privacy rules, and agents covered by another licensee's program. New York sets its own thresholds. Exemptions usually lift some requirements rather than all of them, and they differ by state, so check your own statute.
- How long do we need to keep records of a cybersecurity event?
Five years, for cybersecurity event records. The NAIC model requires licensees to keep records of every event for at least five years and produce them when the commissioner asks. Other records, like claims files, run on separate periods set by your state. If federal health privacy rules also cover you and their period is longer, use that one.
- Can we keep using our current wiki if we move the sensitive content out?
Yes, and for some teams that's the practical answer. Keep general operational documentation where it is, and move the regulated content somewhere you control. The catch is drift. If people are used to adding real examples, they'll keep doing it, so you need a written rule about what goes where and someone checking it.
Wiki Software for Insurance Companies That Meets Your Obligations
Your underwriting guidelines, claims procedures, and complaint records are documentation your team needs open every day, and they're also records a regulator can ask about.
Docmost lets you keep both of those true at once, on infrastructure you own, without adding a vendor to your compliance program.
Or you can talk to our team about what a self-hosted setup would look like for your organization.
