BISS 26005:2026 · Published
BISS — Business Integration Systems Standard
BISS is an independent international standard developed by Eric Chuar Technologies for governing connected business systems and the data and transactions that pass between them. It defines requirements for process ownership, integration contracts, identities, master data, validation, transaction integrity, reconciliation, audit trails, failure recovery, continuity, documentation and responsible supplier exit.
Direct definition
What is BISS?
BISS is an independent international standard developed by Eric Chuar Technologies for governing connected business systems and the data and transactions that pass between them. It defines requirements for process ownership, integration contracts, identities, master data, validation, transaction integrity, reconciliation, audit trails, failure recovery, continuity, documentation and responsible supplier exit.
BISS is intended to make conformance review practical. It does not award status for intent alone: the applicant identifies a bounded system, names accountable owners, operates applicable controls and supplies evidence that can be traced to the current version. The assessment considers design and operation together because a policy that is not followed, or a technical control with no accountable decision path, is not sufficient evidence.
| Acronym | BISS |
|---|---|
| Formal name | Business Integration Systems Standard |
| Reference | BISS 26005:2026 |
| Publisher | Eric Chuar Technologies |
| Maintainer | Eric Chuar Technologies Standards & Conformance |
| Scope | A control and evidence standard for dependable CRM, ERP, POS, HRMS, payroll, booking, inventory and system integrations. |
| Status | Published — assessment required for certification |
| Geographic application | Designed for international and cross-border use |
Purpose and intended outcomes
What BISS is designed to achieve.
A control and evidence standard for dependable CRM, ERP, POS, HRMS, payroll, booking, inventory and system integrations. The standard gives technical and non-technical stakeholders a common way to define expectations, inspect implementation and record residual risk without implying that one control pattern fits every organization.
- Business processes and system ownership defined before integration design
- Explicit API, file and event contracts with controlled identities and changes
- Consistent master data, validation and transaction handling
- Detectable failures, reconciliation and auditable financial or payroll boundaries
- Recoverable operations with documented continuity, training and vendor-exit paths
Who should use it
Accountability spans buyers, builders and operators.
Use is appropriate when the organization can identify the subject of assessment and the responsibilities it actually controls. Suppliers may contribute evidence, but outsourcing work does not outsource accountability for an applicant's decisions.
- Organizations connecting operational and customer systems
- Process, data, finance, payroll and inventory owners
- Integration architects, developers and platform operators
- Implementation partners and managed providers with declared responsibilities
- Auditors and procurement teams evaluating control and continuity evidence
Scope boundary
Systems and lifecycle stages included and excluded.
Included
CRM, ERP, POS, HRMS, payroll, booking, inventory, finance-adjacent workflows, portals, APIs, events, files, master data and operational controls within a declared integration boundary.
Excluded and not implied
It does not certify accounting accuracy, tax or payroll legal compliance, guarantee uninterrupted suppliers, prescribe one vendor, or represent ISO, OpenAPI, IETF, government or statutory certification.
The assessment statement must identify organizational boundary, systems, interfaces, locations, lifecycle stages and material providers. Shared platforms can be included only to the extent that responsibilities and evidence are available. A narrow scope is acceptable when it is described honestly; ambiguous scope is not enlarged by marketing language.
Normative language
How to read the requirements.
Shall
A mandatory requirement for the declared scope. An exclusion needs a justified scope decision, not silent omission.
Should
A recommended practice. A different approach may be accepted when evidence shows an equivalent, context-appropriate outcome.
May
A permitted option that does not become mandatory merely because it appears in guidance.
Evidence
A record, artefact, observation or reproducible result that supports a claim. Evidence must be attributable, current enough for the decision and protected according to sensitivity.
Core principles
BISS principles guide proportionate implementation.
Process owns integration
A technical interface has an accountable business process, decision and exception owner.
Contracts are explicit
Fields, meanings, identities, versions, errors and service expectations are documented before exchange.
Data has stewardship
Master records, validation and change authority are defined across system boundaries.
Transactions are recoverable
Idempotency, integrity, reconciliation and compensation prevent silent duplication or loss.
Failures are operational work
Alerts route to people who can diagnose business impact and restore safe state.
Exit is designed
Documentation, exports, credentials and continuity are planned before dependency termination.
Normative control set
Mandatory BISS requirements.
Every applicable requirement shall be addressed for the declared scope. Alternative control designs may be accepted only when they produce an equivalent, evidence-supported outcome and do not conflict with the requirement. Assessors sample both design and operation and may request additional evidence where a material risk or inconsistency appears. Each control needs an accountable owner, affected boundary, review trigger and exception path; evidence must be attributable to the assessed version or operating period.
- BISS-4.1
Process discovery
The organization shall document the end-to-end process, actors, decisions, records, exceptions and current failure points before integration scope is approved. Evidence: process map and approved problem statement.
- BISS-4.2
System ownership
The organization shall assign business, data and technical owners for every material system and interface in scope. Evidence: ownership matrix and escalation routes.
- BISS-4.3
Integration architecture
The organization shall record source, destination, direction, protocol, trust boundary, dependencies and recovery strategy for each interface. Evidence: integration landscape and architecture decisions.
- BISS-5.1
Interface contract
The organization shall version API, event or file contracts with field meaning, required values, errors, limits and compatibility expectations. Evidence: approved contract and change history.
- BISS-5.2
Authentication and authorization
The organization shall use service identities and least privilege appropriate to each interface and prevent shared uncontrolled credentials. Evidence: identity inventory and permission review.
- BISS-5.3
Data mapping
The organization shall define source-to-target meaning, transformation, units, locale, precision and authoritative ownership for exchanged data. Evidence: mapping specification and examples.
- BISS-5.4
Master data
The organization shall identify authoritative master records and control creation, matching, update, merge and retirement across systems. Evidence: master-data rules and stewardship log.
- BISS-6.1
Validation
The organization shall validate structure, type, range, referential context and business rules before committing exchanged data. Evidence: validation catalogue and negative tests.
- BISS-6.2
Transaction integrity
The organization shall preserve complete and consistent state across partial failures using atomic, staged or compensating patterns appropriate to the workflow. Evidence: transaction design and failure tests.
- BISS-6.3
Idempotency
The organization shall prevent unsafe duplicate effects when requests, events or files are retried or delivered more than once. Evidence: idempotency design and duplicate tests.
- BISS-6.4
Reconciliation
The organization shall compare expected and actual records, totals or states at defined intervals and route mismatches to accountable owners. Evidence: reconciliation output and resolution history.
- BISS-6.5
Financial and payroll controls
The organization shall apply separation, authorization, calculation review, period control and traceability where integrations affect money or payroll. Evidence: control matrix and approved samples.
- BISS-7.1
Privacy and retention
The organization shall minimize exchanged personal data and control purpose, access, retention, deletion and cross-border handling. Evidence: data inventory and retention evidence.
- BISS-7.2
Audit trail
The organization shall record material transactions, configuration changes, approvals and operator actions with protected time and identity context. Evidence: audit-log design and trace samples.
- BISS-8.1
Monitoring and failure handling
The organization shall detect interface delay, rejection, duplication and inconsistency and provide safe retry, quarantine or manual recovery paths. Evidence: monitoring rules and exercised runbook.
- BISS-8.2
Backup and continuity
The organization shall define recoverable configuration and data, dependency order, manual alternatives and restoration tests. Evidence: continuity plan and restoration evidence.
- BISS-9.1
Documentation and training
The organization shall maintain operator, support and change documentation and train affected users for normal and exception workflows. Evidence: accepted guides and training records.
- BISS-9.2
Vendor exit and decommissioning
The organization shall plan export, contract termination, credential revocation, replacement, archive and evidence retention before a dependency ends. Evidence: exit plan and completion checklist.
Required evidence
Evidence must support the claim being assessed.
An applicant should provide the smallest sufficient evidence set rather than an uncontrolled data dump. Records should show who made a decision, what boundary and version it concerned, what result was observed and how exceptions were handled. Sensitive technical, employee or customer material remains protected and is not published merely because it supports assessment.
- Process and ownership maps
- Integration architecture and dependency register
- Versioned API, event or file contracts
- Service-identity and access reviews
- Data mapping and master-data rules
- Validation, idempotency and failure tests
- Transaction and reconciliation evidence
- Financial or payroll control approvals where applicable
- Monitoring, runbook and audit trails
- Continuity, training and vendor-exit records
Assessment and certification
Certification is a controlled decision, not an automatic badge.
The programme confirms the applicant and scope, reviews submitted evidence, performs a technical assessment and records findings. The applicant responds to nonconformities with cause, correction and evidence of effective action. A certification decision is separated from evidence preparation as far as the programme's current operating model permits. Surveillance and renewal consider continuing control operation and material change.
Conformance levels
The declared scope has accountable ownership, a documented baseline and an implementation plan. Foundation is a readiness state, not certification.
Required controls and evidence have been reviewed against the selected standard, with identified nonconformities recorded and corrective actions accepted.
A formal conformance decision has been issued through the EC TECH programme after scope confirmation, evidence review, technical assessment and closure of blocking nonconformities. Certification is neither automatic nor external accreditation.
Nonconformity levels
A condition that does not presently breach a mandatory requirement but could weaken consistency, evidence quality or future conformance if left unattended.
A contained failure to meet a requirement where the control system remains substantially effective. Closure requires proportionate correction and evidence accepted by the programme.
A missing, systemic or materially ineffective control, or a condition that creates unacceptable risk for the declared scope. Certification cannot be granted or maintained until satisfactory corrective action is verified.
Relationship to established frameworks
BISS uses informed alignment without false equivalence.
These references help applicants deepen controls or compare terminology. “Informed by” means a source influenced the requirement design; “maps to” means a documented relationship can be shown; “aligned with” indicates compatible outcomes. None of those phrases means “certified to”. An external framework or law retains its own scope, text, assessment route and authority.
OpenAPI Specification
Its language-agnostic interface description supports explicit HTTP API contracts; BISS also covers business ownership and operations beyond an API description.
RFC 9110 HTTP Semantics
Its definitions of safe and idempotent methods inform retry and side-effect design for HTTP integrations.
ISO/IEC 38505-1:2017
Its data-governance principles inform accountability and stewardship; BISS is not ISO/IEC certification.
ISO 22301:2019
Its continuity-management approach informs dependency, disruption and recovery planning for integrated operations.
NIST Cybersecurity Framework 2.0
Its governance, protection, detection, response and recovery outcomes inform integration security and operational resilience.
Implementation pathway
A practical 30/60/90-day adoption sequence.
The sequence is a planning aid, not a promised certification timetable. Complexity, evidence maturity, third-party access and corrective work determine the real path. Teams should prioritize material risk and sustainable operation rather than creating documents that exist only for assessment day.
First 30 days — map the operating system
- Name process, data and technical owners
- Inventory interfaces and credentials
- Document contracts and master records
- Baseline failures and reconciliation gaps
Days 31–60 — control transactions
- Add validation and idempotency
- Protect service identities and data
- Implement monitoring and quarantine
- Test partial failure and restoration
Days 61–90 — prove operation
- Run reconciliation and continuity scenarios
- Complete operator documentation and training
- Resolve nonconformities
- Submit the bounded integration landscape for assessment
Benefits
What disciplined adoption can improve.
- Fewer silent duplicates, losses and ownership gaps
- Clearer interface and data change control
- Stronger auditability for operational and financial workflows
- More dependable recovery from supplier or system failure
- Better handover and procurement evidence
Limitations
What certification does not prove.
- BISS does not certify financial statements, payroll law or tax calculations
- Conformance cannot prevent every vendor outage or data-quality problem
- Controls apply only to declared processes and interfaces
- BISS is independent EC TECH certification, not external accreditation
Versioning and change control
Current version: BISS 26005:2026.
This page represents the current published 2026 version. Proposed changes are evaluated for need, clarity, measurable effect, compatibility and transition impact. A future revision will identify material changes and whether previously assessed scopes need additional evidence. Editorial clarification does not silently weaken a mandatory requirement, and an applicant cannot select an obsolete clause solely to avoid a current control.
Last reviewed: 6 September 2026. Public revision history will be linked when a subsequent revision exists; no empty or fictional history is presented.
BISS questions and direct answers
BISS is the Business Integration Systems Standard, an independent international standard developed by Eric Chuar Technologies for connected business-process, data and transaction controls.
Assessment enquiry
Request a standards scoping conversation.
Select the standard you want to discuss. This step carries only the selected standard into EC TECH’s existing contact route; do not include passwords, production data or private audit evidence in a public enquiry.
Primary references
Sources reviewed for technical accuracy.
References are linked for comparison and implementation depth. Their inclusion does not imply endorsement, adoption, accreditation or certification of BISS by the referenced organization.
- OpenAPI Specification
- RFC 9110 HTTP Semantics
- ISO/IEC 38505-1:2017 governance of data
- ISO 22301:2019 business continuity
- NIST Cybersecurity Framework 2.0
Last reviewed: 6 September 2026.