SharePoint Embedded

Co-Authoring Under Control: Real-Time Document Collaboration for Audit and Compliance Platforms

Co-Authoring Under Control: Real-Time Document Collaboration for Audit and Compliance Platforms

Co-Authoring Under Control: Real-Time Document Collaboration for Audit and Compliance Platforms

Walk through the document workflow of almost any audit, risk or compliance platform and you will find, somewhere near its heart, a lock. A working paper is checked out to one preparer at a time. A policy is frozen while it circulates for comment. An evidence file is downloaded, edited locally, re-uploaded and reconciled against whatever changed in the meantime. For two decades, software serving the audit and compliance sector has been built on the assumption that collaboration and control are opposing forces — and that in a regulated environment, control must win.

That assumption deserves re-examination, because the technology that created the trade-off no longer defines it. Real-time co-authoring for audit software is now achievable without surrendering any of the things the lock was protecting: named attribution, a complete version record, and governance that stands up to scrutiny. The capability that makes this possible is SharePoint Embedded co-authoring — genuine Word and Excel co-authoring running inside your own product, on documents your application governs.

This article is written for two audiences: product and engineering leaders at audit, risk and compliance software vendors deciding whether their platform should offer real-time collaboration, and technology leads at audit firms evaluating platforms that claim to. We will look at why regulated document work stayed locked for so long, what co-authoring actually provides, how the version and audit record holds together under challenge, and the workflow design question — when to stop co-authoring — that separates a credible regulated collaboration feature from a liability.

Why Regulated Document Work Learned to Lock the File

The lock-and-block pattern was never irrational. A working paper is not merely a document; it is evidence. When a quality reviewer or a regulator asks who reached a conclusion, on what basis, and whether the work was reviewed before sign-off, the document’s history is a large part of the answer. Faced with early collaboration tools that merged changes unpredictably and attributed them loosely, the sector made a sensible engineering decision with the technology available: allow one author at a time, and make every handover explicit.

So the toolkit hardened. Check-in and check-out. Single-writer locks with an override reserved for the engagement manager. Documents emailed for review with initials appended to the filename, then reconciled by hand when two reviewers’ comments came back against different baselines. Every one of these mechanisms bought certainty about who held the pen at the cost of everything else: review became serial rather than parallel, reconciliation became a job in itself, and the busiest weeks of the reporting cycle turned into a queue for the lock.

The irony is that the workaround everyone reached for — email — quietly destroyed the very control the lock existed to protect. The moment a working paper leaves the platform as an attachment, there are two copies, then five, and the platform’s tidy custody record now describes only one branch of the document’s real history. Locking the file did not stop concurrent work; it pushed concurrent work somewhere ungoverned.

The pull of Word and Excel in this sector is not going away, and pretending otherwise is not a strategy. AuditBoard, the audit, risk and compliance platform whose Microsoft Add-In development we helped accelerate, invested in Word and Excel tooling precisely because its customers’ evidence and analysis live in Office documents that need to be connected back to the platform rather than exiled from it. The question for a platform vendor is not whether users will work in Office documents — they will — but whether that work happens inside the platform’s control or outside it.

What Real-Time Co-Authoring Actually Provides

SharePoint Embedded is Microsoft’s container-based document store for applications: your product owns and governs partitioned document storage inside Microsoft 365, and users open those documents in the full Word, Excel and PowerPoint web editors without ever leaving your interface. We have covered what SharePoint Embedded is in depth before; what matters here is the specific collaboration behaviour a SharePoint Embedded development effort inherits, because it answers the sector’s historical objections point by point.

Presence. Everyone in the document can see who else is there and where they are working. In an audit context this is more than a convenience: the preparer can see the reviewer arrive, and the reviewer can see whether the section they are reading is still being written. The social signalling that check-out used to provide crudely — “this is mine right now” — is provided continuously and at finer grain.

Merge behaviour. There is one canonical copy. Concurrent edits are merged continuously as they are made, so there is no fork, no divergent local version, and no reconciliation step in which changes can be silently lost. This is the property that email fundamentally cannot offer and that most home-grown “collaborative” features approximate badly. Conflicts in the traditional sense largely stop existing, because the situations that created them — two people editing two copies — stop existing.

Attribution. Every participant is signed in as a named identity, and every contribution belongs to someone. The fear that co-authoring means anonymous, untraceable change has it exactly backwards: a document edited by five named people in one governed copy is far more attributable than a document emailed to five people and returned as five files. This is the heart of doing collaborative document editing in regulated environments properly — the record of who is not weakened by concurrency; it is strengthened by it.

Autosave. Changes persist as they are made. Nobody loses an afternoon’s testing notes to a crash, and — more important for our purposes — nobody is working in an unsaved local state that the platform cannot see. The same capability that lets you embed Microsoft 365 document editing in your product means the platform’s view of the document and the true state of the document are the same thing at all times.

None of this requires your users to leave your application, and none of it requires you to build an editor. The editing surface is Word and Excel themselves, with the fidelity, formulas and formatting behaviour your users’ documents actually depend on. The conversation around the document travels with it too: comments and replies are attributed to named users in the same way as edits, which matters once we turn to review workflows below.

Version History and the Audit Log: A Record You Can Defend

Collaboration features earn their place in regulated software only if the record they leave behind is stronger than the one they replace. Here the platform provides two layers, and it is worth being precise about what each contributes.

The first layer is version history. As a co-authored document evolves, versions are captured automatically, each attributed and timestamped, and earlier versions can be compared and restored. Nobody has to remember to “save as v2” for the record to exist; the record is a by-product of working. For an audit platform this replaces the most fragile artefact in the old workflow — the filename-suffix version chain — with something systematic, complete and impossible to forget to maintain.

The second layer sits beneath your application entirely. Activity in SharePoint Embedded containers surfaces through the same Microsoft 365 auditing infrastructure that enterprise compliance teams already use for the rest of their tenant estate — file operations recorded at platform level, independent of your product’s code. That independence matters more than it first appears. A change record produced by the same application whose behaviour is under question is only as trustworthy as that application; a record produced by the platform beneath it is evidence of a different order. When a dispute or an inspection asks who changed what and when, “here is the platform’s log” is a categorically better answer than “here is what our application recorded about itself”.

Put the two layers together and you get something the email era never had: a genuine chain of custody. An email trail is a record of transmission — it can prove a document was sent, but says nothing reliable about what changed between attachments. Attributed versions plus a platform-level activity log answer the questions that actually get asked: who touched this working paper, when, what did it look like before, and who signed off the version that became final.

We would add one note of engineering caution from our own work on regulated data systems, such as the Orak integration hub we built for Workplace Pensions Direct to move sensitive pension data securely between payroll systems and pension providers: an inherited record is only defensible if your application does not undermine it. If your product lets documents leak out through ungoverned export paths, the pristine history of the governed copy proves very little. The platform gives you the record; your product design has to keep the work inside it.

The Design Question That Matters: When to Stop Co-Authoring

Here is the part most evaluations miss. The hard product question in regulated collaboration is not how to enable co-authoring — the platform has done that — but when to end it. An audit document has a lifecycle, and unrestricted concurrent editing is only correct for part of it.

Consider the typical shape. In drafting, co-authoring should be at its freest: preparers building a working paper together, in parallel, with presence and attribution doing the work the lock used to do. In review, the ground shifts — a reviewer needs a stable object to review, and a platform ought to be able to constrain editing while comments are gathered, or restrict the preparer to responding rather than rewriting. At sign-off, editing must stop: the version that was reviewed and approved is the version of record, and any further change must mean formally re-opening the document, visibly, with the trail intact. And once a working paper is frozen into the record, it should be held under retention as an artefact that no ordinary user can alter at all.

The platform gives you the enforcement points to build exactly this: permissions can be tightened and released programmatically, a specific version can be designated the signed artefact, and the container boundary makes the enforcement real rather than advisory. (For the mechanics of containers and permissions, see our walkthrough of building a first SharePoint Embedded application.) What the platform cannot know is your domain: which states an engagement moves through, who may transition a document between them, and what each transition means for who can edit. That state machine — engagement workflow mapped onto document permissions — is the genuinely differentiating work in an audit collaboration feature, and it is where product thinking matters far more than raw engineering.

The principle we push clients towards is simple to state: co-authoring is not a mode you switch on, it is a privilege your workflow grants and withdraws. A platform that co-authors everywhere, always, has traded one crude posture (lock everything) for another (lock nothing). A platform that opens collaboration wide during preparation and closes it decisively at sign-off has actually understood the sector it serves — and can demonstrate to an audit firm’s methodology team exactly why each state behaves as it does.

For the technology lead evaluating platforms, this gives you a usefully sharp test to put to vendors. Do not ask “do you support co-authoring?” — every demo will say yes. Ask instead: show me a working paper moving from preparation to review to sign-off, and show me at each transition who can still edit, what the version record captured, and what a reviewer would see if someone tried to change the signed version afterwards. Platforms that have done the lifecycle thinking answer in seconds; platforms that have merely enabled a feature reach for the roadmap slide.

Governance You Inherit Rather Than Build

The final objection usually raised against collaborative editing in regulated software is governance: where does the data live, and what compliance machinery applies to it? The short answer — and we will keep it short, because this article is about collaboration rather than compliance — is that SharePoint Embedded containers live inside Microsoft 365, so data residency follows the tenant geography, and Microsoft Purview’s retention and information-protection capabilities apply to container content. Your customers’ risk teams are being asked to trust a control surface they already know and, in most cases, already operate.

For a product decision, the significant word is inherited. The governance surface arrives with the platform rather than being an estate you design, build and certify yourself — which changes both the cost of the feature and the shape of the security conversation with enterprise customers. Vendors serving many customer tenants will find the architectural side of that conversation — tenancy boundaries, isolation, onboarding — treated properly in our piece on multi-tenant architecture patterns for ISVs.

How McKenna Consultants Can Help

McKenna Consultants has spent more than 25 years building Microsoft document integration and software for regulated industries — from accelerating the Word and Excel Add-In of a major audit and compliance platform to engineering secure data exchange infrastructure for the UK pensions sector. That combination matters here, because a credible co-authoring feature for audit software is exactly half platform engineering and half regulated-workflow design, and teams that bring only one of the two tend to ship the wrong feature well.

If you are an audit, risk or compliance vendor weighing real-time collaboration — or an audit firm trying to separate platforms that co-author under control from platforms that merely co-author — we can help you reason through the lifecycle design, the record-keeping architecture and the SharePoint Embedded build itself. Get in touch and talk it through with us.

Have a question about this topic?

Our team would be happy to discuss this further with you.