Self-hosted document editing for financial services: why the build differs
A bank or fintech risk or credit team that co-edits confidential papers in a public office cloud is moving deal documents, credit memos and board papers to a third party that sets the terms of hosting, support and updates. The direct answer for a regulated firm is to host the editor and the document storage inside your own infrastructure, choose an edition that carries support and signed security updates, and record the editor as an ICT third-party arrangement under DORA. The two candidates are Collabora Online, licensed under MPL-2.0, and ONLYOFFICE Docs, licensed under AGPL-3.0. Both can be wired to a file platform through WOPI or a connector, so the decision rarely turns on features alone. It turns on which edition your risk function can accept, what the vendor contractually commits to, and who answers when a patch is due.
Start with the edition. Collabora's free CODE build is described by Collabora as not recommended for production, so the paid Collabora Online tier, which adds long term support, a service level agreement and signed security updates, is the one to price against a bank's patch obligations. ONLYOFFICE's Community Edition is free to run, but the admin panel, white labeling, scaling for thousands of users and Basic, Plus or Premium support sit in its Enterprise Edition. Confirm in writing which edition, support tier and update channel you would receive, how fixes are delivered to an air-gapped or restricted network, and whether the commercial terms cover your user count. Under DORA Article 28(3), the editor and any hosting or support provider belong in your register of information on contractual arrangements, and Article 30(2) requires the contract to state where data is processed and how data is returned on termination. DeployOpen can prepare the configuration, the evidence and the register entries, but it does not issue attestations, and your auditors and supervisor will judge the result.
Which financial services requirements shape the editor build
This table maps each financial services requirement to the part of the editor build it changes, including the ICT service to log, contract terms, retention and version settings, edit versus view rights, and MFA on the WOPI-connected file platform. Read each row as a design input to settle before the editor is connected, since several of them decide who can edit and what gets kept. The main takeaway is that the document server is one ICT service among several, and its contract, logging and access controls need the same attention as the file platform it serves.
| Requirement | What it means for the build | Evidence to keep |
|---|---|---|
| DORA Article 28(3) register of information | Record the document server, file platform and any hosted AI or support provider as separate ICT arrangements, with the service they support. | Register entries with provider, service type and the critical or important functions each supports. |
| DORA Article 28(8) exit strategy | Plan how documents, version histories and editor configuration move to another storage or editor if the provider or deployment must be replaced. | Tested exit plan covering file export in Office formats and restore into a second environment. |
| DORA Article 30(2) contract terms | Require contract terms that name the locations where documents and editing sessions are processed, advance notice of changes, and data return on termination or insolvency. | Signed contract clauses on processing location, change notice and data return, mapped to the register. |
| DORA Article 26(7) and TLPT context | Scope the editor and WOPI endpoints into penetration testing if they fall within threat-led testing scope, since the article is the only attestation DORA provides for. | Test scope document listing the document server, WOPI host and admin interfaces, with findings tracked to closure. |
| SEC Rule 17a-4(b)(4) retention | For broker-dealers, keep the original and final copies of deal-related communications and documents for the required period, and confirm that editing does not overwrite the retained record. | Retention policy applied to the file platform, with version history and legal hold settings documented. |
| SEC Release 33-8810 IT general controls | Control who can change the editor configuration, the WOPI integration and the document server image, and log those changes as program changes. | Access reviews for administrators, change tickets for editor updates and audit logs of configuration changes. |
| FTC Safeguards Rule, 16 CFR 314.4(c)(5) | For non-bank lenders, require MFA for every user who reaches the file platform that launches editing sessions, unless the Qualified Individual approves an equivalent control in writing. | Written MFA policy for the file platform, enrollment reports and any approved written exception. |
| PCI DSS v4.0.1 scope | If card numbers appear in deal files or credit packs, the editor, storage and document server may fall into the cardholder data environment, so limit storage and logging of that content or segment it. | Scope confirmation from a qualified assessor, data discovery results and network segmentation evidence. |
| Edit versus view rights | Map credit memos and board papers to separate groups, so most staff view while named approvers edit, and disable download or print where policy requires it. | Group-to-permission matrix and periodic review records showing who held edit rights. |
What documents and systems sit inside the editing boundary
Credit memos, underwriting worksheets and loan files hold borrower identities, income and collateral details, internal risk ratings and approval history. They are usually co-edited by credit analysts, relationship managers and credit committee secretaries, and they need a clear record of who changed a rating or a covenant. The most practical pattern is a file platform such as Nextcloud or Seafile, with a WOPI-connected editor opening files from the platform so the document never leaves the bank's network.
- Data: borrower personal data, financial statements, risk grades and approval conditions, which are personal and confidential even before any regulatory label is applied.
- File platform: a Nextcloud or Seafile instance in the bank's data center or private cloud, with a WOPI-connected editor such as Collabora Online or ONLYOFFICE Docs.
- Identity source: the bank's directory, typically Active Directory or an identity provider, with group membership mapped to credit roles so that analysts can edit while reviewers only view.
- Sensitivity: personal data and confidential credit information push the whole editing path, including editor traffic and version storage, into the bank's own hosting and under its records rules.
- Versioning: retained versions of memos are records in their own right, so the retention period and deletion behavior must be set before rollout.
Confirm with your credit risk and records teams which memo versions must be kept, and whether editing sessions create copies outside the file platform.
Deal rooms hold term sheets, due diligence findings, draft purchase agreements and valuation models. Access is often restricted to a named deal team, and the list of people with access can change during a transaction. The main risks are leakage of material non-public information, unplanned sharing with advisers and the need to revoke access quickly when a deal ends.
- Data: draft agreements, valuation models, diligence reports and counterparty information, often subject to confidentiality undertakings and insider lists.
- File platform: a segregated project space on the file platform, with one folder or team per transaction, so that access can be removed as a unit.
- Identity source: the bank's identity provider with time-limited groups for deal teams, plus a separate path for external advisers where the bank permits external accounts.
- Sensitivity: material non-public information and counterparty confidentiality mean that external editing sessions and external AI services are generally out of bounds.
- Exit handling: closing a deal should revoke access, freeze versions and move records into the retention store.
Confirm with legal and compliance whether external advisers may hold accounts, and how insider lists are kept in step with folder membership.
Board papers and committee minutes are drafted by company secretariat staff, reviewed by executives and approved by directors. They often include strategy, capital plans, remuneration and supervisory correspondence. Version control matters because the final approved minutes must be distinguishable from drafts, and directors often need read-only access with a controlled way to annotate.
- Data: strategy papers, capital and liquidity plans, remuneration decisions and minutes of decisions taken.
- File platform: a restricted secretariat space on Nextcloud or Seafile, with read-only shares for directors and an editor for the secretariat and named authors.
- Identity source: a dedicated board group in the directory, reviewed each time a director joins or leaves, and kept separate from general staff groups.
- Sensitivity: the content is often price-sensitive or supervisory, so editing sessions should remain inside the bank's boundary and avoid public AI features.
- Approval trail: the final minutes should be locked and their version history preserved as evidence of governance.
Confirm which papers must be kept as formal records, and whether directors need offline copies on managed devices.
Regulatory submissions include supervisory reports, incident notifications, capital and liquidity returns and responses to information requests. These documents often carry deadlines and must be traceable to named preparers and reviewers. They also tend to reference customer data, which means the editing boundary must cover the whole preparation chain, not only the final file.
- Data: supervisory returns, incident reports and correspondence that may include customer or counterparty personal data.
- File platform: a controlled space on the file platform with checkout or locking, so that one preparer edits at a time when a return is final.
- Identity source: the bank's identity provider with roles for preparer, reviewer and approver, and strong authentication for anyone who can submit.
- Sensitivity: supervisory data and incident details are confidential, and the ICT providers in the chain fall under the bank's DORA register of contractual arrangements.
- Audit trail: access and edit events must be logged in a way that can be produced to a supervisor on request.
Confirm with the regulatory reporting team which submission data is considered critical, and which ICT providers touch each step of the chain.
Some payment-related files contain primary account numbers, such as chargeback case files, merchant onboarding forms or card dispute correspondence. PCI DSS applies only where cardholder data or sensitive authentication data is stored, processed or transmitted, or where a system could affect the security of the cardholder data environment. A document that contains no such data sits outside that scope, so the bank should not extend PCI controls to every payment-related folder by default.
- Data: merchant onboarding forms, dispute files and chargeback evidence, some of which may contain card numbers or other account data.
- File platform: either a separate instance inside the cardholder data environment, or a segregated space on the main platform that is kept out of the editing path for any file holding card data.
- Identity source: a dedicated group for payments operations, with multi-factor authentication for every user who can reach a file system holding account data.
- Scope decision: a data discovery pass on the file shares determines which files actually hold cardholder data, and the scope decision should be documented and reviewed.
- Editor scope: if the editor or document server can read these files, it may become part of the scope, so the boundary must include it.
Confirm with your QSA or internal assessor whether the editor and its document server are in scope, and whether redaction of card data before editing is a practical option.
Which editor edition a bank should expect support and signed updates from
A bank should expect signed security updates and a contracted support path from the edition it runs in production, and the free builds do not provide that. For Collabora Online, the free CODE edition is described by Collabora as not recommended for production. The paid Collabora Online adds tested updates, security fixes and support, so a bank's editing tier should be the paid product. Collabora's pricing page lists a Business plan at 3 euros per user per month for up to 99 users, including long term support, a service level agreement, signed security updates and customer portal access. Enterprise pricing for 100 or more users is quoted with volume discounts and adds integration support, customization services and roadmap input. Confirm current terms, support windows and the portal process with Collabora before you rely on them in a procurement file.
For ONLYOFFICE, the Community Edition is licensed under AGPL-3.0 and is supported through GitHub and the community forum, with configuration done through config files only. A bank that wants an admin panel, scaling for thousands of users and Basic, Plus or Premium support should evaluate the Enterprise Edition, as ONLYOFFICE's edition comparison describes. The Developer Edition is a commercial license for software vendors that embed the editors in services they provide to customers. A bank that uses the editors internally does not fit that case, so ask whether it is needed at all. Whichever vendor you choose, ask for the written support tier, the security advisory channel, the patch turnaround commitments and the signing process for updates, then have your third-party risk team check them against your DORA register of information entry for the editor.
Which editing platforms fit financial services and why
Financial teams need an editor whose support terms, signed updates and hosting location match their vendor risk file. The options below separate the paid support tiers from the free builds and name the condition under which each one stops being a fit.
Collabora Online paid edition
The paid edition is built on LibreOffice technology and adds long term support, a service level agreement, signed security updates and customer portal access, per Collabora's pricing page. It fits banks that want a supported editor with a documented update path. It fails when the team needs Office-identical layout for complex templates, so test fidelity on real credit memo and board paper templates. Confirm the support terms in writing before procurement.
Collabora CODE for test environments only
CODE is the free development edition, released roughly once a month as a rolling release. Collabora describes it as suited to testing, home use or small teams and not recommended for production. Use it to prototype WOPI wiring and template testing in a non-production zone. It fails the moment it holds live deal documents, because it carries no vendor support or tested production updates.
ONLYOFFICE Docs Enterprise Edition
The Enterprise Edition adds an admin panel, white labeling, scaling for thousands of users and Basic, Plus or Premium support tiers, according to ONLYOFFICE's edition comparison. It suits banks that need administrative control and a named support tier for the document server. It fails if the support tier chosen does not match the bank's incident response expectations, so confirm response commitments and which tier covers the document server itself.
ONLYOFFICE Docs Community Edition
The Community Edition is AGPL-3.0 licensed, with support through GitHub and the forum and configuration through config files only. Version 9.4 removed the 20 simultaneous connection limit from the Community Edition. It fits non-production use or low-risk teams that accept community-level support. It fails for regulated deal and credit documents when the bank requires a contractual support scope, an admin panel or formal change control.
Nextcloud as the WOPI host
Nextcloud Server is AGPL-3.0 licensed and acts as the file host that opens documents in the editor, through its office configuration. It fits banks already storing deal files in a self-hosted Nextcloud instance inside their own network. It fails if the host is not on the editor vendor's supported integration list for your chosen version, or if WOPI traffic reaches an editor outside the bank's boundary. Document the pairing in the vendor risk register.
Seafile as an alternative host
Seafile is released under GPLv2 with an additional permission to link with OpenSSL, and is listed among WOPI integrations for Collabora and ONLYOFFICE. It fits teams that want a file sync platform focused on storage and versioned libraries. It fails when the bank needs the richer sharing, audit and admin features it already relies on elsewhere, so confirm version history and permission granularity against the retention policy before choosing it.
How a bank rolls out co-editing in phases
The sequence moves from a third-party register entry and edition decision through a controlled build, identity and role design, and fidelity testing on real bank templates, ending in a pilot and a production cutover with a documented exit plan. Each phase closes with a record the risk, audit and procurement teams can review.
Scope the service and enter it in the third-party register
The bank's ICT risk owner, procurement lead and business sponsor define which functions the editor supports, which document classes it will hold (deal documents, credit memos, board papers) and whether the service supports a critical or important function. The engagement is recorded as an ICT third-party arrangement in the register of information, and the contract is checked against the locations and data-return terms that DORA Article 30(2) requires. Done means a signed scope document and a register entry the compliance team has accepted.
Select the editor edition and support model
The team compares Collabora Online and ONLYOFFICE Docs against the bank's formats, WOPI or API integration needs and support expectations. Community builds are not suited to production in the form the vendors describe, so the decision covers which paid edition carries long-term support, signed security updates and a service level agreement, and what the license terms allow. The output is a written edition decision, a support contract draft, and an exit or replacement option documented for the register.
Build the environment inside the bank network
The platform team deploys the file platform, the document server and the WOPI connection inside the bank's own data center or cloud account, with no path to public office services. Ingress is limited to known internal hosts, and the team records the image sources, patch channel and approved build for each component. Done means a documented architecture, a tested update procedure, and a network check showing that editing traffic stays on approved paths.
Integrate identity and multi-factor authentication
Identity engineers connect the file platform to the bank's directory and single sign-on so that every editor and viewer authenticates through the existing control set. Multi-factor authentication must cover every individual who accesses the system, unless the Qualified Individual approves an equivalent control in writing under the FTC Safeguards Rule where that rule applies. Done means test accounts from each group sign in through the approved path and the MFA exception list, if any, is signed.
Design edit and view roles by document class
Business owners and the access governance team map each folder and document class to the groups allowed to edit, to view, to comment and to share outward. Credit memo and board paper folders usually need narrower edit rights than general deal rooms, and the design records who approves a change to those rights. Done means a role matrix signed by the business owners and tested with negative cases, such as a viewer attempting to save or an external user attempting to download.
Configure version retention and audit logging
The records and security teams set version retention periods, deletion rules and legal hold handling for each document class, and turn on audit logging for access, edits, shares and permission changes. They confirm which log events feed the bank's security monitoring and where logs are stored for retention. Where the bank is also a broker-dealer or subject to SEC recordkeeping, the team checks the retention design against the applicable rule with counsel. Done means a retention schedule, a log sample reviewed by the second line, and a restore test for a prior version.
Test fidelity on the bank's own templates
Business analysts supply the actual credit memo and board paper templates, including tables, headers, footers, comments, tracked changes and any signature blocks, and the team opens, edits and exports them in the chosen editor. Differences in layout, fonts and pagination are logged against an acceptance list agreed with the document owners. Done means a fidelity report that shows which templates pass unchanged, which need a documented workaround, and which stay in desktop Office.
Run a pilot and cut over to production with an exit plan
A single business unit uses the service for a defined period with a named support path, and the team reviews incidents, access requests and version recovery requests before wider rollout. Production cutover then follows a documented change record, and the exit plan covers data export, format fallback and contract termination steps, as DORA Article 28(8) expects for services that support critical or important functions. Done means a pilot review signed by the business owner, a cutover approval, and an exit plan filed with the third-party register.
Evidence examiners and auditors ask for, and what produces it
This table maps each piece of evidence a bank's examiner, internal auditor or SOX assessor is likely to request to the component that produces it. Read it as a checklist for design: if no component owns an item, the evidence will be missing at audit time. The auditor, examiner or regulator issues the opinion; the table only identifies what the record should contain.
| Evidence item | What it shows | Producing component and owner |
|---|---|---|
| DORA register entry and contract clauses | Each ICT arrangement for the editing platform, with provider, locations of service and data processing, and data return terms under Articles 28(3) and 30(2) | Contract and vendor register, held by third-party risk; the DeployOpen engagement scope and the editor's support contract feed it |
| Tested exit strategy documentation | Documented exit and transition plan for the editing stack under Article 28(8), with evidence the export of documents and version history was tested | Runbook and test records from the file host and document server; owned by the operations team and reviewed by third-party risk |
| Access reviews and role lists for edit versus view | Who can edit, comment or view each deal, credit or board folder, and when that was last reviewed | File host group and share permissions, exported on a schedule; approved by the data owner |
| MFA configuration evidence | Proof that every account reaching the file host and editor requires multi-factor authentication, or an approved equivalent under 16 CFR 314.4(c)(5) where that rule applies | Identity provider policy and file host authentication settings; exported configuration and sign-in logs |
| Version and audit log samples supporting SEC 17a-4 or internal retention policy | Samples showing versions, deletions and access to board papers and credit memos are retained and retrievable for the required period | Log store and file host version history, with retention rules set by compliance; the auditor samples the output |
| Change records for IT general controls under SEC Release 33-8810 | Approved, tested and recorded changes to the editor, file host and access configuration, covering program changes, computer operations and access | Change management system ticket history with approvals, plus deployment logs from the infrastructure pipeline |
| Patch and signed update records from the vendor | Versions applied, dates of security updates and the signature check performed before deployment, showing the edition in use is supported | Patch log kept by operations; vendor advisories and release notes for the chosen editor edition; confirm support terms with the vendor |
| Swift CSCF or PCI DSS evidence (only where in scope) | Swift CSCF attestation or PCI DSS scope records, needed only if the editor or its storage touches payment messaging or cardholder data | Scope statement from the security team; a Qualified Security Assessor or the Swift assessor issues the opinion, not the platform |
What financial services teams ask before co-editing self-hosted
What does self-hosted document editing cost, and what drives the price?
The software licence is only one part of the bill. The main cost drivers are the edition you pick, the number of named users, the server footprint for concurrent editing, the integration with your file platform, and the support level your bank requires. Community builds are free to download, but the Collabora Online pricing page lists its Business plan at 3 euros per user per month for up to 99 users, including long term support, an SLA and signed security updates. ONLYOFFICE prices its Enterprise and Developer editions separately. Ask any vendor or partner for a quote that separates one-time work (design, installation, hardening, testing) from recurring items (subscriptions, support, hosting, and upgrades). DeployOpen issues fixed-scope quotes from a written scope rather than a public price list.
How long does a self-hosted editor rollout take in a bank?
The timeline depends on the size of the estate, the number of editor nodes, and how many approvals sit in front of production. The steps usually include a design phase, a build in a non-production environment, identity and file platform integration, security testing, format testing on your own templates, a pilot group, and a staged rollout. Change control, vendor risk review and the DORA register update can add time that the software itself does not. No duration is fixed in this page. Ask for a milestone plan in the written scope, with a named exit criterion for each stage.
What must the bank provide before an editor partner can start?
The partner needs access to a few things that the bank owns. These are an identity provider for single sign-on and group mapping, network paths between the file platform, the editor and the users, a decision on which hosts may call the WOPI endpoint, the retention policy for document versions, and a named approver for go-live. Your records team should confirm how long deal papers, credit memos and board materials must be kept, since SEC Rule 17a-4(b)(4) sets a three-year minimum for certain broker-dealer communications and your own policy may be longer. Your security team should confirm the audit logging standard and where logs are stored.
Can internal IT staff run a self-hosted document editor themselves?
Many teams can run the editor once it is built, provided they have container or Kubernetes skills, a patch routine and someone who understands WOPI. The harder parts are sizing for concurrent editing, sticky routing so that every editor of one document reaches the same pod, and testing updates before they reach users. The Collabora Online Helm chart documentation says horizontal pod autoscaling is disabled because scaling breaks collaborative editing, so replicas must be set by hand. Ask your team to name who owns each of these tasks after go-live, and whether that owner has time for monthly updates. DeployOpen can plan, implement, harden, back up, upgrade and document the platform as a fixed-scope engagement or a retainer, with your team taking on what it can.
Can view-only rights on confidential documents be enforced in a self-hosted editor?
View and edit rights are enforced by the file platform and the WOPI host, not by the editor itself. The file platform decides whether a session opens in read-only mode, and the editor must respect that decision. Test this during the build by opening the same credit memo as a viewer and as an editor, then trying to save, copy, print and download. Also check that revoking access ends open sessions, and that group membership changes take effect promptly. Write the results into your access control evidence, since the FTC Safeguards Rule requires multi-factor authentication for any individual accessing an information system, which the identity layer should enforce before the editor opens.
Does DORA apply to a self-hosted document editor?
DORA applies to the financial entity, and it reaches the editor when the editor is an ICT service that supports the bank's activities. Regulation (EU) 2022/2554 has applied since 17 January 2025 to 20 types of financial entity. Article 28(3) requires a register of information covering all contractual arrangements for ICT services, and Article 30(2) requires contracts to state where data is processed and to cover data return on termination. If the bank runs the editor itself, the open-source licence is not the contract that matters, but the support contract and the hosting arrangements are. Ask your legal and third-party risk teams to classify the editor, confirm the register entry and set an exit plan under Article 28(8) if it supports a critical or important function.
Can an optional AI assistant in the editor be kept off external services?
Yes, if you choose an editor that ships with AI off and gives you control over the provider. Collabora Online 26.04, announced on July 23, 2026, adds an optional AI assistant across Writer, Calc and Impress. It is off by default, and administrators choose the AI provider and whether it is hosted externally or on their own infrastructure. Keep it disabled until your data classification and model review are complete. If you enable it, restrict it to self-hosted endpoints, log its use, and confirm with your security team that prompts containing customer or deal data never leave your boundary. Check the editor's telemetry and update settings as well, so that no other outbound call bypasses that decision.
Which editor edition gives a bank signed updates and support?
Community builds are for testing and are not the right choice for a bank's production estate. Collabora describes its free CODE edition as suited to testing, home use or small teams, and not recommended for production. The paid Collabora Online Business plan includes long term support, an SLA, signed security updates and customer portal access. ONLYOFFICE Enterprise Edition adds an admin panel, scaling for thousands of users, and Basic, Plus or Premium support, while Community support runs through GitHub and the forum. Confirm the support window, the patch cadence and how signed packages reach an offline or restricted environment before you sign.
Questions to put to an implementation partner before signing
Start with DORA, because it decides whether the engagement can proceed at all for a regulated entity. Ask the partner to show how their services will appear in your register of information on contractual arrangements for ICT services, which DORA Article 28(3) requires, and to supply the fields you need to populate it. Ask for a documented, tested exit strategy and transition plan, as Article 28(8) expects for services that support critical or important functions. Ask where the service is delivered and data processed, and how they will give advance notice of any change, since Article 30(2) requires the contract to state these points. Also confirm how data is returned if either party becomes insolvent or the contract ends. Ask who holds these documents and when they were last exercised.
Next, pin down the edition and the update chain. The free Community builds of ONLYOFFICE Docs and Collabora's CODE edition are not positioned for production, so ask which edition is proposed, in writing, and what support level, service level agreement and long-term support branch come with it. For Collabora, the Business plan includes long-term support, a service level agreement and signed security updates, and the Enterprise plan adds integration support. For ONLYOFFICE, ask which features and support tier apply. Ask who verifies and applies each security update to your environment, how signatures are checked, how the patch window is agreed, and how testing is done before a production update. Ask for the names of the people accountable for each step.
Then test the access model and routing. Ask how edit and view rights map from your identity provider into the file platform and into the WOPI permissions the editor receives, and which group, not individual user, controls edit rights for deal rooms and board papers. Ask how version history is retained for credit memos, how long versions are kept, and how that setting is evidenced for examiners, including the logs that show who opened and changed a document. Ask the partner to demonstrate WOPI routing: that every editor of one document lands on the same pod through the WOPISrc parameter, that a pod failure is handled without corrupting an open session, and what test evidence is produced. Finally, ask for a fidelity test on your own bank templates, covering tables, tracked changes, comments and fonts, with the results recorded before go-live.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For financial document editing, that means the editor, its document server and the file store stay under the institution's control, with the evidence needed for DORA and internal audit reviews agreed in writing before work starts.
How we scope
- Written scope covers the editor edition, user counts, document types and the file platform it connects to.
- Scope records which groups can edit and which can only view deal, credit and board documents.
- Scope lists where the editor and document server run, so the DORA contract location and data processing points are documented.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- Deploy the chosen editor and document server in your infrastructure, with WOPI traffic restricted to known hosts.
- Test Office file fidelity using your own credit memo, deal and board paper templates before go-live.
- Configure version retention, audit logging and access controls to match the institution's records policy.
- Run security testing on the editing integration, including the WOPI endpoints and the file platform connection.
How we hand over
- Deliver architecture, configuration and runbook documentation, including the update and patch procedure.
- Provide a tested exit and backup procedure so documents and editing services can move if the platform changes.
- Prepare evidence packs of configuration, access and audit settings for your internal and external auditors.
- Walk administrators through routine operations, monitoring and the process for applying signed updates.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover version upgrades of the editor and file platform, tested against your templates.
- Periodic security testing of the editing stack can be scheduled alongside the retainer.
- Confirm with the editor vendor which support plan and signed update terms apply to your user count before you commit.
