Security commitments with an evidence boundary
This page describes the WiBiz-wide control model. It does not convert a policy requirement into a claim that every provider, system, or client build has identical settings. Exact implementation and evidence belong to the assessed build.
Each section separates the control commitment from the proof required for a client or product claim. If current proof is missing, the approved status is not yet confirmed, partial, or an open exception.
Governance and evidence
Security requirements have named owners, review dates, evidence references, and documented exceptions.
A policy alone is not treated as proof. Build claims require current configuration, test, log, contract, or independent-review evidence.
Infrastructure and data location
WiBiz operates a cloud-only model and records the actual service providers, environments, regions, and cross-border paths for each production build.
There is no universal WiBiz hosting region. The applicable Build Security and Data Annex is the source for a client's exact architecture.
Access and identity
Access must be named, approved, least-privilege, role-based where available, removed promptly when no longer needed, and protected by strong authentication.
Production claims require account inventories, authentication evidence, access approvals, review records, and recorded provider limitations or exceptions.
Encryption and secrets
WiBiz requires protected transport, appropriate at-rest protection, and controlled handling of keys, credentials, and service identities.
The exact protocol, storage encryption, key owner, rotation model, and backup protection are verified and recorded per system. We do not apply one algorithm claim to every provider by default.
Secure delivery
Security and privacy requirements are defined before build approval, then tested against the deployed release before production clearance.
Evidence may include design review, code review, dependency and secret checks, application tests, authorization tests, isolation tests, deletion tests, restore tests, and independent testing where the risk tier requires it.
Vulnerability management
Suspected vulnerabilities are triaged, owned, remediated, retested, and closed through versioned evidence. Critical and High findings block release unless an accountable, expiring exception is approved.
Independent testing is scoped to named assets and releases. A test is point-in-time evidence, not proof of the entire programme.
Incident response
WiBiz maintains incident classification, escalation, containment, evidence preservation, recovery, legal assessment, client communication, and corrective-action procedures.
Notice timing follows applicable law and the signed client agreement. We do not replace contract-specific notification commitments with a blanket public deadline.
Continuity and recovery
Service dependencies, backup method, recovery objectives, restore evidence, and continuity responsibilities are defined for each applicable production build.
Provider-native history is not automatically treated as an independent backup. Recovery claims require a successful, scoped, dated test record.
Vendors and subprocessors
Providers are classified by data access and service criticality, reviewed before approval, and reassessed after material change.
The exact provider role, service, data, location, contractual safeguards, review date, and open evidence are recorded. Unknowns remain visible until verified.
What a client receives
Before a production release, the applicable assurance tier identifies the data map, hosting, regions, service providers, access model, retention, recovery, testing, unresolved risks, evidence IDs, and responsible approvers for that exact build.