Security architecture you can inspect
Understand how ZoikoSuite approaches identity, authorization, encryption, workload trust, isolation, supply-chain security, telemetry, incident response and sovereign deployment — with status and scope visible for every claim.
Eight public control areas
Enough for a security reviewer to assess approach and posture, without revealing configuration that would assist an attacker.
Zero trust & authorization
No implicit network trust. Every request carries identity context and is authorized at request time.
Identity & SoD
Human identity, role, attribute, entity scope, delegation and segregation of duties.
Data protection
Encryption in transit and at rest, with protection scope stated per deployment.
Machine identity
Service-to-service trust with workload identity. Current and target state both published.
Isolation & deployment
Tenant and environment boundaries, with deployment choice affecting the boundary model.
Key custody & secrets
Key ownership models and secret handling, with eligibility by deployment.
Telemetry & response
Security events linked to audit and evidence systems, with defined response principles.
Secure SDLC & supply chain
Engineering requirements for signing, scanning, provenance and SBOM.
Authorization resolves against context, not just role
Role alone is insufficient in a multi-entity platform. The same person may hold different authority in different entities, and segregation must hold across both.
WHAT AN AUTHORIZATION DECISION RESOLVES
- Authenticated identity · human or workload principal
- Role · what function the principal performs
- Attributes · conditions that qualify the role
- Entity scope · which legal entities, sites or units are in view
- Delegation · authority granted by another principal, with limits and expiry
- Segregation of duties · conflicts evaluated before the action is offered
SEGREGATION OF DUTIES
Preparer, reviewer, approver and executor are independently permissioned. Where a conflict would arise, the action is not presented — rather than presented and then rejected after the fact.
DELEGATION
Every delegation carries a granting principal, a scope, a limit and an expiry. A delegation without an expiry is not a delegation; it is a permanent grant under another name.
Six steps, and a deny path that is not an error
Authorization happens per request. Network position grants nothing, and a prior successful request authorizes nothing later.
Request received
No implicit trust from network location, VPN or prior session.
Principal authenticated
Human or workload identity established for this request.
Context resolved
Entity, jurisdiction, data classification and effective policy version.
Policy decision
Role, attribute, delegation, limit and segregation evaluated together.
Deny or step up
A denial is a governed outcome with a reason — not a system error.
Decision recorded
Allow and deny both produce an evidence record with actor and basis.
Protection scope, without inventing algorithm claims
What is protected, where the boundary sits, and which deployment the statement applies to. Specific cipher suites and configuration are provided under controlled access, not published.
Current state and target state, both published
This is the one area where the honest answer is a direction of travel rather than a finished control. Publishing only the target would be status inflation.
CURRENT STATE
Service-to-service authentication with scoped credentials and least-privilege service accounts. Service principals appear as named actors in the evidence record, so an action taken by a service is attributable.
- Authenticated service connections
- Scoped credentials per integration
- Service principal recorded in audit events
- Error isolation between integrations
Deployment choice changes the boundary, and the responsibility
Tenant and environment boundaries differ by deployment mode, and so does who holds the keys. Both are stated rather than averaged.
Security events are evidence, not just logs
Security decisions link to the same audit and evidence systems that carry governance decisions, so a security question and a governance question resolve against one record.
WHAT IS CAPTURED
- Authentication and authorization outcomes, including denials
- Privileged and administrative actions
- Access to data classified as sensitive, with recorded purpose
- Configuration and policy changes with actor and version
- Export events with destination and basis
- Integration and service-principal activity
DETECTION PRINCIPLES
- Alerting on anomalous privileged activity
- Segregation-conflict attempts surfaced, not silently denied
- Integration failure isolated rather than cascading
- Retention aligned to the evidence model
NOT CLAIMED
No claim of complete detection coverage, guaranteed detection time, or continuous 24/7 monitored SOC is made on this page. Operational detail is confirmed in security review for your deployment.
Engineering requirements and their evidence surfaces
What is required of engineering, what evidence each produces, and which of those can be shown publicly.
Code review
Peer review required before merge, with security review for designated sensitive areas.
Dependency scanning
Automated scanning of third-party dependencies with defined remediation handling.
Static analysis
Automated code analysis in the build pipeline.
Signed artifacts
Build artifacts cryptographically signed and verified before deployment.
Provenance & SBOM
Software bill of materials and build provenance published to customers on request.
Penetration testing
Independent security testing. Report scope, date and findings summary under NDA.
Vulnerability disclosure
Published route for reporting a suspected vulnerability, with acknowledgement commitment.
Remediation SLAs
Internal severity-based remediation targets.
Five stages, with communication defined in advance
What counts as a security event, how it moves, and what a customer should expect to hear — decided before an incident rather than during one.
Event identified through telemetry, report or disclosure route.
Severity assessed against defined criteria, owner assigned.
Containment actions taken and recorded as evidence.
Affected customers notified per contractual and regulatory obligations.
Post-incident review with findings and remediation tracked to closure.
WHAT A CUSTOMER CAN EXPECT
- Notification consistent with contractual and regulatory obligations
- A named point of contact for the duration
- Factual updates as assessment progresses, including "still assessing"
- Post-incident review findings where the customer is affected
WHAT IS NOT COMMITTED HERE
- A specific notification window — that belongs in a contract
- A guaranteed containment or resolution time
- Public disclosure of incidents not affecting the customer
- Any assertion about incident history
Every claim mapped to its evidence and owner
Each material claim carries a status, a scope, an evidence route, a content owner and a last-reviewed date.
Route diligence to the evidence that exists
Controlled-access evidence is released under NDA, scoped to your deployment. A review that returns "not available" is still a successful review.
AVAILABLE THROUGH SECURITY REVIEW
- Completed security questionnaire — scoped to your deployment
- Architecture brief — zero trust, identity, isolation, telemetry
- Penetration test summary — under NDA, with scope and date
- Remediation targets — severity-based internal SLAs
- Key custody options — eligibility for your deployment and region
- Gap statement — what is not available, stated directly
Request security review
Enough to scope a response, nothing more.
Bring the question your questionnaire cannot answer
Most security questionnaires ask whether a control exists. The more useful question is which deployment it applies to, who holds the key, and what happens when it fails. Those answers need your context, not a generic pack.
No certification, attestation, detection guarantee, notification window or availability commitment is made outside an approved commercial document.
Talk to a solutions architect
Every section of this page was readable without it.
Certification, encryption, keys, testing and response
Direct first sentences, then qualified detail. Every answer is present in the page source.
No. Security framework readiness is not presented as certification, and no independent assurance exists to share. If your procurement process requires a SOC 2 report or ISO certificate as a gate, that gate cannot currently be met. Knowing so early is more useful than discovering it at contract stage.See compliance status