Centvra
Menu

Guide · Compliance · Requirements

What to Look for in Compliance Management Software

A compliance status is only useful when you can see who is accountable, what supports it and what still needs attention.

Start with the questions your current process struggles to answer.

Key takeaway

You will learn when manual tracking becomes difficult to sustain, which compliance software capabilities matter, and what your organisation needs to settle before buying. An ISO/IEC 27001 programme provides a practical example.

Choose a System You Can Keep Current

01 Find the buying trigger

Start with the status
you cannot explain.

For compliance leaders, programme owners and procurement teams starting a search, the first requirement is the question the current process cannot answer reliably. An audit request, expansion to another business unit or a new obligation may expose different failures.

Missing recordsCan another person reconstruct the evidence and approval behind the reported position?
More units or countriesCan you tell which requirements apply locally and who maintains the response?
A change in requirementsCan you find affected controls and track the response through to review?
Repeated chasingCan owners and reviewers see the status between reporting dates?

Spreadsheets, folders and email can work for a small, stable programme with disciplined ownership. They become harder to sustain when a tracker, evidence folder, approval thread and action log tell different stories. Replacing them only helps if the new system connects those records and the people responsible for them.

Trace one real status. Choose a recent report. Ask someone other than its author to find the supporting evidence, reviewer decision and next action. Record each point where they need to chase a person or search another file.
02 Follow the decision

Connect the work
behind the status.

A useful system links the source requirement, its applicability, the responsible unit and owner, the relevant control, the evidence and assessment, and any unresolved action. It must preserve the time period and scope behind each conclusion.

AccountabilityWho performs the work, who reviews it, who can accept an exception and where overdue action escalates. Reassignment retains the earlier history.
AuditabilityWhich evidence version and assessment supported a decision at the time. A current file upload date alone cannot reconstruct an earlier position.
TransparencyWhich reviews, evidence items and corrective actions remain open, with a route from a summary to the underlying record and suitable role access.

ISO/IEC 27001 as a worked example

An organisation chooses quarterly access reviews for selected systems. The frequency is illustrative, not a universal standard requirement. Its tracker says the review is complete, yet the reviewer found accounts awaiting removal. The system should keep the review outcome and the open corrective work visible together.

What was reviewed?

Record the systems, business unit, period, owner and reviewer with the dated access list used.

What was decided?

Keep the evidence version and assessment, including the reviewer decision and its date.

What remains open?

Show the removal requests, action owners, due dates, closure evidence and next review.

For an information security management system, also ask how risks, treatment decisions, controls and the Statement of Applicability stay linked. A shared control can support another standard or local obligation, but its evidence must suit each requirement’s scope and period. Completing one review does not make every linked requirement satisfied.

03 Test product depth

Check the foundations.
Then test what varies.

A basic compliance workflow needs records for requirements, sources, owners, controls, evidence, assessments, findings, actions and approvals, with permissions, reminders and usable reporting. Availability and depth vary by product and package. These six tests expose the differences that may change fit:

01 · Local applicability

Can a group control coexist with separate applicability, ownership and decisions for each legal entity or business unit? Can a local variation be recorded without losing the group relationship?

02 · Shared control relationships

Can one control link to several requirements, with evidence reused only where its scope and period fit? If the shared control changes, which requirements need reassessment?

03 · Change to response

Can a new requirement or internal change trigger applicability and impact review, assigned action, approval and closure linked to its source? An alert alone is not a managed response.

04 · Diagnosable gaps

Can you distinguish an unmapped requirement, a control not yet assessed, evidence awaiting review and an open finding? A single completion percentage obscures these different jobs.

05 · Monitoring and follow-up

Can scheduled and connected checks expose overdue work and failed feeds? Confirm the update frequency, the last successful transfer and who investigates exceptions.

06 · Relevant content

Is content supplied, licensed separately or maintained by your team? Check jurisdictions, subjects, languages and versions. Reviewers should be able to correct and approve any extracted suggestions.

Prioritise your actual scope. An initial information security programme may need stronger control, evidence and action relationships than a large regulatory content feed. Frequent local changes across units make content coverage and impact assessment more significant. A feed alert is a starting point, not a reviewed response.
04 Prepare the first release

Set a first scope
you can keep current.

You can begin selection before every record is tidy. Define the buying trigger, the initial programmes and units, the existing requirements and controls, the unresolved ownership decisions, and the people who will maintain content, reviews, permissions and connections after launch.

Scope and pressureState which programme and units go first, what can follow later and any external audit, customer or regulatory date.
Records and decisionsMark what is confirmed, duplicated or unresolved. Keep a representative control, its evidence, review result and open action together.
Capacity after launchIdentify who can maintain the structure and content and who can decide exception and closure rules. Record missing decisions as assigned internal work.

You're ready to talk to suppliers when you can

  • A named sponsor and bounded first scope
  • Three questions the current process struggles to answer
  • Representative records and unresolved decisions
  • People and time to run the programme after launch

Prepare a one-page brief with those points and the capabilities needed to answer your three questions. Use it to start matching products and discussing fit.

Centvra's view

An approaching audit or a wider programme often reveals how much reporting depends on individual knowledge. Trace one important status back to its owner, evidence and unresolved actions. Where that trace breaks is where the software requirement begins.

This guidance is for planning a software purchase. Which obligations apply will depend on your organisation's own circumstances.

Six Checks Before You Shortlist

  • 01 · Evidence That Remains ExplainableHistory

    A live report changes as the programme changes. You may still need to explain a previous assessment to management, a customer or an auditor. Establish whether the system preserves the records and decisions used at that time, including what happens when evidence is replaced or deleted.

    System requirement

    Retain and export the evidence, assessment and approval history needed to reconstruct a past reporting position.

  • 02 · Access for Contributors and ReviewersParticipation

    Central compliance teams often depend on occasional contributors in business units and external reviewers. Their access, permitted actions and licence costs can affect whether the intended workflow is practical.

    System requirement

    Give each role a usable contribution or review route, with access restricted to the relevant records and a clear licence basis.

  • 03 · Visible Integration FailuresData flow

    A dashboard can appear current after an evidence feed stops updating. For each proposed connection, identify the system of record, the refresh method and the person who will investigate a failed or incomplete transfer.

    System requirement

    Show when data was last successfully updated, flag missing updates and assign responsibility for restoring the feed.

  • 04 · Content and Module DependenciesCoverage

    Framework templates, regulatory feeds, AI tools and technical monitoring may come from different modules or licences. Confirm which party maintains the content and whether your required jurisdictions and standards are covered in the proposed package.

    System requirement

    Price and document the complete scope, including content subscriptions, required modules, connector support and update responsibilities.

  • 05 · Ownership After ImplementationMaintenance

    Someone must maintain the organisation structure, owners, mappings, schedules and reports as the business changes. Ask which routine changes your administrators can make and which require supplier services.

    System requirement

    Fit the administration work to the people and time you can provide, including training, support and expected configuration costs.

  • 06 · A First Release That Fits the DeadlineRollout

    An audit date does not make historical records easier to migrate. Decide which current activities must run in the system first, which older records must remain accessible and how work will be reconciled during the transition.

    System requirement

    Define the first release, migration responsibilities, acceptance criteria and the approach for keeping current compliance work moving.

Fit-based software matching

Find software that fits how your organisation operates

Tell us what the software must support, how your teams work and which delivery constraints matter. Centvra uses those inputs to build a focused supplier shortlist.

Start matchingFree to use · No paid ranking
Matching modelRequirements-led

Your operating brief

CapabilitiesWhat the software must support
Ways of workingWorkflow, ownership and scale
Delivery constraintsHosting, integration and support

Fit-based shortlist

Matched supplierFunctional fit
Matched supplierOperating fit
Matched supplierDelivery fit

Try it with your requirements

Describe your institution in plain language. Only three minutes, no signup to see your matches.

This example is ready to run or edit it to match your own situation.

Common questions

When should we move from spreadsheets to compliance software?

Consider a system when maintaining ownership, evidence links, review history or a reliable view across teams takes repeated manual reconciliation. First identify the failures and their consequences. A stable programme with clear ownership may still be manageable through a disciplined manual process.

Can one compliance system cover ISO 27001 and local regulations?

Potentially, if it supports the necessary content, business-unit applicability, shared controls and separate assessments. Check the actual jurisdictions, obligations and workflows you need. A common control or evidence item can support several requirements, but each use still needs a suitable scope and assessment.

Does ISO 27001 require dedicated compliance software?

ISO 27001 does not require a particular compliance software product. Software can help coordinate recurring work, records and follow-up actions. The organisation remains responsible for its information security management system and the decisions within it; purchasing a product does not establish conformity or certification.

Does continuous monitoring mean every control is checked automatically?

No. A programme may combine automated signals with periodic reviews, owner attestations and human assessment. Ask which controls and systems are covered, how current the information is and what happens when evidence is missing or a result requires investigation.

What should we prepare before speaking to suppliers?

Bring a defined first scope, your buying trigger, representative records and the questions you need the system to answer. Name likely owners and reviewers, record unresolved decisions and explain your implementation capacity. You can refine the detail during selection without presenting incomplete records as settled requirements.