Zebsoft Compliance Software Modules

THE STRUCTURAL DISTINCTION

These terms describe different layers of the platform. Keeping them separate makes the system easier to navigate and prevents one configurable function being mistaken for a fixed standalone product.

A reusable platform function such as auditing, risk assessment, document control, training, change or task management. The same capability can support several subjects.

A configured application of capability for a defined purpose. An internal-audit module and supplier-audit module can share the audit engine while using different scope and workflow.

A requirements framework such as ISO 9001, ISO 14001 or ISO 27001. Standards can draw on multiple modules and capabilities without becoming the operating system themselves.

SHARED ENGINE—DIFFERENT CONTEXT

The module applies classification, questions, responsibilities, permissions and workflow appropriate to the subject. It does not require a new isolated platform for every variation.

Information-security risk, health-and-safety risk, environmental risk, supplier risk and business risk can share the same assessment logic while retaining distinct context, ownership and control expectations.

Internal audits, supplier audits, site inspections and framework-specific audits can use shared planning, evidence, findings and follow-up capability with different programmes and criteria.

Safety events, information-security incidents, complaints, nonconformities and near misses can use shared reporting and investigation functions with different classifications and escalation routes.

MODULE GROUP 01

Plan assurance activity, collect evidence, record findings and connect identified weakness to accountable follow-up.

Record what did not meet the expected condition, preserve its context and initiate investigation, correction, corrective action or risk review as appropriate.

MODULE GROUP 02

Connect what the organisation has decided, the risks that could prevent it and the approved information that directs the work.

Maintain structured risk context, assessment, ownership, controls, treatment, review and current status without reducing every risk type to an isolated spreadsheet.

Connect ISO 27001 Annex A control decisions to applicability, justification, implementation context, ownership, supporting evidence and assurance activity.

Govern authoring, review, approval, publication, access, communication, revision and withdrawal for information that carries operational authority.

MODULE GROUP 03

Keep events, decisions and required responses visible from initial record through authorised closure and effectiveness review.

Control proposed change through context, impact assessment, review, approval, implementation, communication and verification rather than treating approval as the finish line.

MODULE GROUP 04

Make approved requirements visible to the people affected and return completion, evidence, questions and exceptions through structured workflows.

Define role requirements, assign learning or evidence, review submitted records, monitor status and expiry and keep competence decisions with authorised people.

Give employees a current view of applicable information, changes, acknowledgements, assignments and required responses while managers retain visibility of exceptions.

Request information and evidence from external parties through a controlled route and return submissions to internal owners for review, decision and continued monitoring.

MODULE GROUP 05

Apply structured responsibility and evidence to operational resilience, physical or digital assets and the work required to keep them controlled.

Maintain asset identity, location, responsible person, inspection, maintenance, certification, condition and supporting records for operational use.

Connect asset strategy, lifecycle risk, integrity decisions, change, investment and assurance without confusing strategic governance with routine maintenance scheduling.

MODULE GROUP 06

Structure registers, decisions, due diligence, communication and monitoring where responsibilities extend across personal information or external organisations.

Maintain personal-data and processing context, ownership, lawful basis, retention and supporting information as part of a governed privacy system.

Assess change and privacy risk through a controlled impact route, retain competent review and connect approved treatments to evidence and follow-up.

Control initial qualification, evidence, evaluation, approval and tender decisions before moving selected suppliers into onboarding and continued assurance.

HOW MODULES CONNECT

The exact route varies by configuration, but the operating principle remains consistent: context enters the platform, required activity is owned and visible, evidence returns to the record and a competent person verifies the outcome.

01

A requirement, risk, incident, document, person, supplier, asset or other governed subject establishes why work is needed.

02

The applicable module determines questions, stages, permissions, ownership, notifications and required evidence.

03

The responsible people complete the required activity, communicate, submit evidence or record a decision through the controlled route.

04

Current status, missed responses, conflicting information and overdue work remain visible to authorised roles while action is still possible.

05

A competent person reviews the information and decides whether it is accepted, rejected, returned, escalated or subject to further action.

06

The record retains the operation, evidence, review, exception and outcome so reporting is based on traceable activity rather than reconstructed claims.

CHOOSE THE RIGHT VIEW

Use the page that matches the question you are trying to answer. The routes below describe the architecture, reusable functions, responsibility contexts and external requirements separately.

See how the platform, domains, capabilities, portals and ZAP workflows fit together as one connected assurance environment.

Explore the reusable functions that perform audit, risk, document, incident, change, training and action work across the platform.

See how the platform is applied to quality, information security, health and safety, environment, suppliers, assets and other responsibilities.

Find framework-specific information for organisations operating recognised standards and regulatory requirements through the platform.

PRACTICAL QUESTIONS

Module availability, naming and workflow depend on the agreed platform configuration. These answers explain the structural principle rather than defining a universal customer setup.

A module is a configured application of shared platform capability for a defined operational purpose. It brings relevant fields, classification, permissions, workflow, evidence and reporting together without requiring an isolated system for every subject.

No. A capability is the reusable function, such as risk management or auditing. A module applies that capability to a context, such as supplier audit, information-security risk or a site inspection.

No. A domain is the responsibility context, such as quality, health and safety or information security. A domain normally uses several modules and capabilities to operate its controls.

Not necessarily. The enabled functions, configuration, user roles, portals, workflows and implementation scope depend on the customer’s agreed requirements and subscription arrangement.

Yes, where configured and authorised. An incident can prompt risk review, action, change, document revision, training or audit verification while retaining the relationship between the records.

No software module guarantees conformity, certification or legal compliance. Zebsoft helps organisations operate approved controls and retain evidence. Competent people remain responsible for requirements, configuration, decisions and assurance.