Controls you can verify, and claims we do not make.

What applies here, and where it varies and what applies to an application.

The controls described for Zemerc applications are distinct from the controls that apply to this public website. Application controls operate under the architecture and agreement for each product; this section addresses the website only.

• No personal data is collected merely by browsing

  The current website sets no cookies, runs no analytics, advertising or tag-management technology, and makes no third-party requests during ordinary browsing. Typefaces are served from the Zemerc website itself.

• One validated enquiry route

  Every submission is validated before processing. Oversized requests are rejected, automated abuse is rate-limited using a one-way representation of the originating network address, and suspected automated submissions are discarded without creating an enquiry record.

• Controls must operate in practice

  If an enquiry cannot be delivered, the form reports the failure. The enquiry is not queued for later delivery, and no success confirmation is shown unless delivery has succeeded.

Access is governed by identity, not on working practice.

Roles, tenancy and approval authority are assigned to users and enforced by the application. This makes access and approval controls independent of informal working practice.

• Role-based access

  Users are assigned roles that determine what they may view, change and approve. Administrative actions are governed by explicit permissions.

• Segregation of duties

  Where segregation of duties is required, authorship and approval are assigned to different authorised users. Draft records do not progress until the required approval has been completed.

• Authority is explicit

  Where supported, approval limits, delegations and named approvers are maintained as governed configuration records, including signature references associated with management-of-change approvals.

Separation is enforced by the database itself.

Several Zemerc applications enforce tenant isolation at database level, reducing reliance on application-layer checks alone.

• Tenant isolation

  Several applications enforce tenant isolation through database-level row security, so access control does not rely solely on the user interface.

• Reference data is governed once

  Equipment, personnel, organisations and locations are maintained as governed reference data within a tenancy and referenced where needed rather than duplicated across records.

• Boundaries between applications

  Applications do not depend on direct access to one another’s internal tables. Where information passes between teams, a defined record is exchanged and each application maintains its own governed representation and history.

Append-only audit history, because subtraction is the risk.

Record history forms part of the governed record. Audit history is therefore preserved rather than edited retrospectively.

• Immutable where it matters

  Readings, approved assessment revisions and audit entries are preserved as immutable records where required. Corrections are made through governed substitution or supersession so the original record remains available.

• Supersession, not editing

  Approved engineering records are superseded rather than overwritten. Where other records depend on a superseded record, those dependencies are identified for reassessment.

• Effective dating

  Where calculation methods are effective-dated, historical periods can be reproduced using the method that applied at the relevant time.

Your records remain yours, including on the way out.

Operational data remains under the organisation’s control, supported by governed export so authorised records can be retrieved in a usable form.

• Governed export

  Applications provide controlled import, migration and export functions so authorised records can be brought in and retrieved through governed processes.

• Your governance rules, enforced

  The organisation defines who may change a record, what constitutes a valid entry and who may approve it. The application enforces those approved rules.

• Provenance preserved

  Migrated records retain their provenance, and the approved cut-over point identifies when the application became the system of record.

No application depends on another one hostage.

Application independence also limits the potential impact of an issue in one system on other Zemerc applications.

• Independently operable Each application has its own users, data,

  controls and release lifecycle. No application requires another Zemerc product in order to remain operable.

• No shared database

  There is no mandatory portfolio-wide data store behind the applications. Where information passes between products, a defined record is exchanged rather than internal databases being merged.

• Independently replaceable

  Each application is independently operable and can be replaced without requiring changes to other Zemerc applications.

Deployment options is your decision.

Several applications support Zemerc-hosted deployment, deployment in a client cloud tenancy or deployment within the client network. Supported options are confirmed for each application.

• Zemerc hosting is optional

  It is a supported deployment model for applicable applications, not a condition of using them.

• Deployment within your controlled environment

  Where an application supports deployment within the client network, the client’s existing infrastructure and security controls continue to apply.

• Defined per application

  Deployment options vary by application, and some modes remain under development. The supported options are confirmed for the application being considered.