Compliance software onboarding checklist: move from files to a working system

Onboarding compliance software succeeds when the right records, owners and decisions move into a process people will actually use. The goal is not to upload every old PDF and declare victory. Start with the obligations you must manage, identify the authoritative record for each, test permissions and reminders, and make sure a real user can retrieve evidence and close an action. Use this checklist as a rollout plan for a UK organisation. Adapt it to your sector, privacy obligations, vendor contract and the features you have independently verified.

This guide owns the *implementation* task after a platform has been chosen. The existing Complys software buyer's guide and features checklist cover selection and comparison. Contractor onboarding is a different workflow: it brings a supplier into a job, while this checklist brings an organisation's compliance records and users into software.

Copyable rollout plan

Organisation/team: ______ Project owner: ______ Executive sponsor: ______ Supplier/contact: ______ Go-live target: ______ Pilot area: ______ Systems to replace or connect: ______ Sensitive data types: ______ Decision maker for go-live: ______

Do not treat every row as automatically handled by the vendor. The organisation remains responsible for the accuracy of its source data, appropriate access and its own legal decisions. Capture which features are actually present in the selected plan and which tasks remain manual.

1. Define the first useful outcome

Pick a narrow result that matters: for example, every worker's required training is visible with a named owner; every company insurance expiry has a reminder; or a manager can produce a current evidence pack for a client request. Write an acceptance test before importing data. “All documents uploaded” is not an outcome if records have no owner or wrong dates.

Identify who creates a record, who checks it, who approves it, who gets a reminder and who can close an exception. Map at least one complete workflow: a certificate is requested, received, checked for scope and validity, stored, expires, renews and is replaced. A workflow reveals configuration gaps that a screenshot demo hides.

2. Clean the source data before import

Make an inventory of current spreadsheets, cloud folders, email attachments, paper and other systems. For each record type, decide which is authoritative. A duplicate insurance policy with a different expiry date is an exception to resolve, not two records to upload. Match people to the right employer and site; match assets to stable IDs; retain version history where it is needed. Mark expired records as expired rather than making them appear current because they were newly uploaded.

For each batch, record source location, date range, count, owner, lawful purpose, retention decision and destination. Test the import with a small representative set, including a record with missing information and one with a renewal. Confirm that dates, names, attachments and access rights survived. If the platform does not offer import, plan controlled manual entry and independent spot checks. Do not promise a seamless migration without a verified tool.

3. Check privacy, contract and security

Work out whether the supplier will process personal data on your behalf, and what data you truly need in the platform. The Information Commissioner's Office (ICO) explains controller-processor contract requirements under the UK GDPR, including processing instructions, security, sub-processors, assistance and end-of-contract provisions. Its guidance notes it is under review following the Data (Use and Access) Act, so check the current version when contracting. Do not assume every compliance document is suitable to upload just because the platform accepts PDFs.

Set permission roles before importing worker, health, identity or safeguarding records. Test them with actual user accounts: can a supervisor see only what they need, and can an ordinary user see anything they should not? The National Cyber Security Centre's cloud principles give a framework for evaluating security, including access and authentication. Ask the supplier about multi-factor authentication, audit logs, backups, incident support, data location, sub-processors and export/deletion at exit; verify the answers in current product and contract material. Avoid a public share link containing sensitive data unless its scope and recipients have been deliberately controlled.

Decide retention by record type. The ICO's storage-limitation guidance says the UK GDPR does not set one universal period for personal data. Use applicable sector law, claims needs and purpose; do not copy a vendor default into every category. If a new processing use is likely to create high risk to individuals, assess whether a data protection impact assessment is needed under current ICO guidance.

4. Configure obligations and reminders

Set a record type, accountable owner, review or expiry trigger, reminder lead time and escalation path for each obligation. Check whether the date is truly an expiry date, a review date, a service due date or merely the document issue date. A health and safety policy might need review after change; an insurance policy has a stated end date; a worker qualification may have an issuer-defined validity period. They should not all use the same annual reminder.

Test what happens when a reminder is ignored, an owner leaves, or a record is rejected. A system that sends an email to a departed employee has not managed the risk. Keep a queue of missing or disputed data with a named resolver. Where the law or regulator sets a due date, link the internal rule to a current source. Where it is a company or client standard, label it as such.

5. Run a realistic pilot

Choose a real team, project or property and a representative set of records. Ask users to complete the activities they will perform after go-live: add a worker, request a certificate, check its scope, report a defect, assign an action, find the current policy, respond to an expiry and export evidence. Note where they abandon the process or create workarounds. If mobile/offline access matters, test it on the devices and connectivity they actually have; do not assume it exists.

Compare the pilot data with the old source. Count records and attachments, inspect a sample of dates and scopes, and ask the accountable owner to sign off. Test an exception, not only a perfect record. For example, import an insurance certificate that expires next week and verify it is flagged without being labelled “compliant” merely because a file exists.

6. Train, cut over and review

Train each role on its own tasks and limits. An administrator needs to configure permissions and export data; a site supervisor needs to see today's actions; a worker may only need to acknowledge a briefing. Give users a short procedure and contact for errors. Announce the cutover date and what happens to the old spreadsheet. Read-only archiving may be appropriate for evidence, but do not leave two editable “master” systems running indefinitely.

Before go-live, require the owner to show one end-to-end workflow and an evidence export. Check user access, overdue items, data quality exceptions, unresolved privacy questions and vendor support route. Record a go/no-go decision and any compensating manual process. Review the rollout after the first real renewal or inspection request. If no one uses the action queue, the configuration or ownership model needs work.

Where Complys fits

Complys has public UK guides and a buyer guide describing document, worker, RAMS and related workflows. The exact host, product plan, import facility, role permissions, offline access, export, support and retention controls must be checked against the live implementation before this onboarding checklist becomes a Complys-specific promise. A useful CTA is to pilot one real compliance workflow with verified Complys features and check the result against the acceptance test above. Do not tell readers that any software makes them compliant by itself.

Source/claim, owner and writer QA

Ownership: No exact compliance-platform onboarding checklist owner appeared in targeted live Complys search. The buyer and features guides cover selection; contractor onboarding pages cover a different subject. Repository and gated-content review remains a publication gate.

Writer-side QA: Copyable rollout table; practical data, security, pilot and acceptance steps; source/claim and intent boundaries; no unverified Complys feature claims. READY is writer-side complete for independent review, not approval to publish.