Wiki Software for Financial Services: Compliance and Data Sovereignty

Phil

— 9 min read

A regional bank's compliance team discovered that loan officers had been documenting workout strategies for troubled commercial loans in the company wiki. The wiki was hosted by a US SaaS vendor with servers split across three AWS regions. Some of those workout strategies included customer financial details, risk assessments with personally identifiable information, and internal credit committee decisions that regulators consider protected records.

The bank's information security team hadn't classified the wiki as a system containing regulated data. Nobody had flagged it during the last audit. The wiki vendor's standard terms of service gave the vendor broad rights to access customer data for "service improvement" purposes.

When an OCC examiner asked where the bank's workout documentation was stored and who had access to it, the compliance team couldn't give a clear answer. The system wasn't in their data inventory. The access controls hadn't been reviewed against regulatory requirements. The data residency question produced visible discomfort.

This is what happens when financial services firms treat their wiki like any other productivity tool. It isn't.

The regulatory problem with documentation tools in finance

Financial services is one of the most heavily regulated industries on earth. The regulations don't just govern how you handle money. They govern how you handle information about money, about customers, about decisions, and about risks. Your wiki is an information handling system. The moment someone puts regulated content into it, it falls under the same rules as your core banking platform or your trading systems.

Most IT teams don't think about it that way. They evaluate wiki software based on features, user experience, and price. Compliance gets consulted, if at all, after the purchase decision. That's backwards.

Here's the regulatory framework you're actually dealing with.

Sarbanes-Oxley (SOX)

SOX applies to publicly traded companies and requires internal controls over financial reporting. Section 302 requires CEO/CFO certification that controls are effective. Section 404 requires management assessment of internal controls, including IT controls.

If financial information or information that informs financial reporting lives in your wiki, that wiki is part of your SOX control environment. You need documented access controls, change management, and audit trails. If someone can edit a page describing revenue recognition methodology and there's no record of who changed what and when, that's a SOX control gap.

Gramm-Leach-Bliley Act (GLBA)

GLBA's Safeguards Rule requires financial institutions to develop, implement, and maintain an information security program to protect customer information. "Customer information" is defined broadly: any nonpublic personal information about a customer.

If your wiki contains customer names associated with financial products, account details, or credit information, GLBA applies. You need to know where this data is, who can access it, and how it's protected.

MiFID II

For firms operating in European financial markets, MiFID II imposes record-keeping requirements on investment decisions, order execution, and client communications. If your wiki documents investment rationale, trade execution procedures, or client interaction protocols that reference specific client situations, those records fall under MiFID II retention requirements.

MiFID II requires retention of records for at least five years (seven years in some cases). Those records need to be retrievable and producible to regulators on request. If they're stored in a wiki, the wiki needs to support this.

PCI DSS

If any part of your organization handles payment card data and your wiki contains any reference to cardholder data environments, security procedures for those environments, or network diagrams showing card data flows, PCI DSS requirements extend to the wiki. PCI DSS Requirement 7 mandates access restriction to cardholder data on a need-to-know basis. Requirement 10 requires tracking and monitoring all access.

Regulatory examination expectations

Beyond specific regulations, financial regulators (OCC, FDIC, SEC, FCA, BaFin, and others) have general expectations about information management. They expect you to know where your data is. They expect you to control who can access it. They expect audit trails. They expect you to be able to produce records on demand.

A wiki that can't satisfy these expectations is a liability during an examination.

Data residency requirements

Financial regulators in many jurisdictions have explicit or implicit data residency requirements. Some examples:

EU/EEA. Post-Schrems II, transferring personal data outside the EU requires specific legal mechanisms. Financial regulators like BaFin and the ECB have additional expectations about data location for regulated entities. The European Banking Authority's guidelines on outsourcing arrangements require that data location doesn't impair supervision.

Singapore. MAS Notice 655 sets requirements for data that's outsourced offshore, including notification to MAS and ensuring that data remains accessible for regulatory purposes.

Australia. APRA's CPS 234 requires regulated entities to manage information security when data is held by third parties, with specific requirements for data location transparency.

United States. While there's no single federal data residency law, specific regulations (like those governing national security-related financial data) restrict where certain data can be stored. State-level regulations add another layer.

The practical impact: when your wiki contains regulated financial data, you need to know exactly where that data is physically located, who can access the infrastructure, and whether the data location complies with applicable regulations.

Cloud wiki vendors typically host data across multiple regions and may move data between regions for performance or availability reasons. Getting a definitive answer about data location from a cloud vendor is often harder than it should be.

Audit trail requirements

Financial regulators love audit trails. For good reason. When something goes wrong (and in finance, things go wrong regularly), regulators need to reconstruct who knew what, who decided what, and who changed what.

For your wiki, this means:

Every edit must be attributed and timestamped. Version history isn't optional. It's a regulatory requirement. And it needs to be reliable: if version history can be deleted or modified, it's not a trustworthy audit trail.

Access must be logged. Not just edits, but views. If a regulator asks who saw the document outlining the decision to approve a high-risk loan, "we don't track page views" is not an acceptable answer.

Permission changes must be recorded. When someone gains or loses access to a space containing financial records, that change should be logged with the date, the person who made the change, and the reason.

Retention must match regulatory requirements. SOX records must be retained for seven years. MiFID II records for five to seven years. Your wiki's audit trail retention needs to match or exceed these periods. If your wiki vendor retains audit logs for 90 days, you have a compliance gap.

Access control for sensitive financial documents

In financial services, access control isn't just good practice. It's a regulatory requirement that gets tested during examinations.

You need multiple layers:

Separation between public and restricted content. General company information (policies, org charts, HR content) should be separate from regulated financial content. This separation should be structural, meaning different spaces or sections with different permissions, not just a naming convention.

Role-based access that reflects regulatory boundaries. People in the front office shouldn't access compliance investigation files. Compliance shouldn't have write access to trading documentation. These separations reflect regulatory expectations about information barriers (commonly called Chinese walls in financial services, though the industry is moving away from that term).

Individual accountability. No shared accounts. Every access must be attributable to a specific person. This is a consistent theme across financial regulations.

Periodic access reviews. Financial regulators expect you to review access rights regularly, not just set them and forget them. Quarterly access reviews for systems containing regulated data are standard practice. Your wiki should make it easy to see who has access to what, so these reviews aren't an enormous manual effort.

Multi-factor authentication. MFA for accessing systems containing regulated financial data is an expectation, not a nice-to-have. Your wiki should support MFA natively or through integration with your identity provider.

Why banks can't use SaaS wikis for certain content

Let's be specific about this. The issue isn't that SaaS wikis are inherently bad. For general corporate content, they're fine. The issue is that certain categories of financial services content have requirements that most SaaS wikis can't meet.

Regulatory examination access. Regulators may require access to your systems during an examination. If your data is in a SaaS wiki, providing regulator access means involving the vendor. Some vendors don't have processes for this. Some regulators aren't comfortable accessing data in a third-party system.

Outsourcing notifications. In many jurisdictions, storing regulated data with a third-party service provider triggers outsourcing notification requirements. You may need to notify your regulator before moving regulated data to a SaaS vendor, and the regulator may have objections.

Vendor risk assessments. Financial regulations require you to perform due diligence on third-party service providers that handle regulated data. For a wiki vendor, this means assessing their security practices, business continuity, incident response, subprocessor management, and financial stability. Most wiki vendors don't undergo the kind of examination that financial regulators expect.

Contractual requirements. Financial regulators often require specific contractual provisions with service providers, including audit rights, data access guarantees, incident notification requirements, and exit provisions. Standard SaaS terms of service rarely include these provisions, and many wiki vendors aren't set up to negotiate custom contracts with individual customers.

Data sovereignty and control. Some financial data needs to stay within your direct control. Not "in a vendor's cloud within your country," but on infrastructure you own and operate. This is particularly true for data related to supervisory reporting, anti-money laundering investigations, and sanctions screening.

The self-hosted alternative

Self-hosting your wiki solves most of these problems. Not because self-hosting is inherently more secure (it's not, automatically), but because it gives you control over the factors that regulators care about.

With a self-hosted wiki:

  • Data is on your infrastructure, in your data centers, under your physical and logical control
  • No outsourcing notification is required for the wiki itself
  • No vendor risk assessment is needed for the wiki platform (though you still need to assess the underlying infrastructure if you use cloud IaaS)
  • Audit trails are under your control, with retention policies you set
  • Regulators can access the system through your existing examination processes
  • Access controls are managed through your existing identity infrastructure

Docmost is a good fit for this use case. It's self-hosted, supports SSO and LDAP for integration with enterprise identity systems, includes role-based access control with space-level permissions, and maintains version history for audit trail purposes. You deploy it on your infrastructure, and the data stays where you put it.

Practical setup for a financial services wiki

Here's the approach that works.

1. Data classification first

Before setting up the wiki, classify your content. What's regulated? What's sensitive but not regulated? What's general corporate content? This classification drives everything else.

Create a content policy that specifies what types of information can and cannot be stored in the wiki. Be specific. "No customer PII in the wiki" is clear. "Be careful with sensitive data" is useless.

2. Architecture that reflects classification

Set up separate spaces for different classification levels. At minimum:

  • General corporate space (all employees, open)
  • Department-specific spaces (team members edit, others view or no access)
  • Regulated content spaces (restricted to authorized personnel, audit trail enabled)
  • Compliance/legal spaces (restricted to compliance and legal teams)

Configure permissions before anyone starts creating content. It's much harder to reclassify and move content after the fact.

3. Integration with enterprise identity

Connect the wiki to your Active Directory, LDAP, or SSO provider. This ensures that:

  • User provisioning and deprovisioning happen through your existing processes
  • Access reviews can be conducted using your existing IAM tools
  • MFA policies apply to wiki access
  • Terminated employees automatically lose access

4. Audit trail configuration

Enable all audit logging. Configure retention to match your longest regulatory requirement (typically seven years for SOX). Ensure logs are exported to your central logging system so they're available even if the wiki itself has issues.

5. Backup and recovery

Financial regulators expect business continuity planning for all systems containing regulated data. Your wiki needs regular backups, tested recovery procedures, and documented RPO/RTO targets. Self-hosting gives you full control over backup processes, including where backup data is stored.

6. Change management

Changes to the wiki's configuration, especially access controls and security settings, should go through your organization's change management process. Document who can make changes, what approval is required, and how changes are recorded.

7. Regulatory examination preparation

Have a plan for how you'll handle a regulatory examination that involves wiki content. Know how to produce specific pages and their history on demand. Know how to demonstrate your access controls. Know how to show your audit trails. Practice this before the examiners arrive.

The conversation to have internally

If you're reading this as an IT director or compliance lead at a financial services firm, the most useful thing you can do is have an honest conversation about what's actually in your wiki today.

Chances are good that people have been using it to document things that fall under one or more of the regulations discussed here. They're not doing it maliciously. They're doing it because the wiki is convenient and nobody told them not to. The wiki was probably adopted as a general productivity tool, and nobody assessed it against financial regulatory requirements.

That conversation isn't comfortable. It usually reveals gaps. But discovering those gaps yourself is much better than having an examiner discover them. And fixing the gaps typically means either moving to a wiki platform that meets your regulatory requirements or restricting what content goes into your current platform.

It's not a conversation that gets easier with time. The longer regulated content accumulates in an inappropriate system, the bigger the remediation effort.

Read more