Protect critical systems without losing sight of state, ownership or recovery.

Cybersecurity architecture should make protected scope, security-relevant signals, incident and resilience state, responsible ownership, response and recovery, and evidence visible, without implying tools or service coverage that have not been approved.

Explore cybersecurity architecture Discuss your security architecture

CYBERSECURITY INTENT ROUTER

Eight questions buyers bring to a security conversation

Scroll the strip and pick the one closest to yours.

Understand protection

"What is in scope, and how is protection state represented?"

Evaluate security operations

"How are signals triaged, owned and resolved?"

Plan incident readiness

"Who owns response, recovery and status communication?"

Integrate security data

"How do approved systems, events and evidence connect?"

Review privacy & identity

"How are security, privacy and access responsibilities separated?"

Protection & Resilience Architecture

Seven layers wrapped around what you protect

Each ring has its own source of truth. Read from the center out.

Trust rails

Evidence rail

Response & recovery

Incident / resilience

Triage & ownership

Signals

Protected
scope

Layer, treatment and authoritative-state rule for each protection layer
Layer	Treatment	Authoritative-state rule
Protected scope	System, service, workload, environment, dependency or business surface.	From current product or customer architecture; synthetic in public examples.
Security-relevant signals	Generic event, signal or issue references.	Signal state belongs to the responsible monitoring source.
Triage & ownership	Reviewer, accountable owner, queue and decision state.	Never implies 24x7 staffing or managed triage unless documented.
Incident / resilience	Active, degraded, contained, recovering, resolved, unknown.	Marketing never self-declares resolution.
Response / recovery	Action, handoff, workaround, restoration, escalation.	Action authority and recovery ownership explicit.
Evidence rail	Source, time, owner and references.	Never becomes a compliance or breach-prevention guarantee.
Trust rails	Security, Privacy, Disclosure, Status, Trust Center.	Linked, never duplicated or contradicted.

Service passport

SPECIMEN · SYNTHETIC DATA

Scope

Customer billing service (synthetic)

Owner

Platform Operations

Environment

Production

Dependencies

Payments provider · degradedDegraded

Data sensitivity

Category: confidential

Last confirmed

Today 09:40 · service registry

PROTECTED SCOPE & SERVICE CONTEXT

Start by naming exactly what is protected, and by whom

Scope identity, owner, environment, dependencies, data category, security boundary and freshness. No PII, secrets or internal topology in public examples.

RESPONSIBILITY BOUNDARY

Zoiko-operatedPlatform runtime and Zoiko-managed services, where documented.

SharedConfiguration, integrations and incident communication.[cite: 7]

Customer-controlledEndpoints, identity, network, data, continuity and your own response.

Responsibility rule. Protection is shared. Zoiko never automatically owns customer endpoint, identity, network, data, continuity or incident-response responsibilities.

Review scope

SECURITY SIGNALS & SOURCE INTEGRITY

Every signal carries its source, scope, time and owner

Security signals

SPECIMEN · SYNTHETIC DATA

Signal	Source	Affected scope	Observed	State	Owner
SIG-2207	Monitoring source	Billing service	09:12 - 09:38	Investigating	Security on-call
SIG-2211	Provider notice	Payments dependency	08:50 - 09:40	Acknowledged	Platform Ops
SIG-2214	Log pipeline	Reporting jobs	Last seen 3 h ago	Stale · telemetry delayed	Observability team
SIG-2219	Customer report	Partner portal	09:41	Queued	Security triage

Severity appears only where the responsible system defines a scale. Unknown or delayed telemetry is never shown as secure or normal.

INCIDENT & RESILIENCE STATE

When the waves hit, every state says who defined it

Six domains, each using the responsible process's own semantics. Public service state always comes from System Status.

Incident

Contained

Suspected · active · contained · recovering · resolved · unknown

Never invented from marketing telemetry.

Service resilience

Degraded

Operational · degraded · disrupted · recovering · unknown

System Status stays authoritative.

Dependency

Unknown

Available · degraded · unavailable · unknown

Source and last-confirmed time shown.

Customer impact

Not confirmed

Affected · potentially affected · not confirmed

No customer identity or confidential detail.

Communication

Public status

Internal · customer · public status · resolved notice

No parallel public status feed.

Evidence

Private

Reference, owner, time, state, action pointer

Sensitive evidence remains private.

View incident states

RESPONSE, RECOVERY & CONTINUITY

From disruption back to calm, with an owner at every step

Contain / restrictA state or action category, only where supported.

Mitigate / workaroundTemporary is never shown as resolved.

Restore / recoverTied to authoritative service state and owner.

Rollback / compensateOnly where the product supports it.

EscalateSecurity, platform, provider, privacy, legal or support.

Customer / provider handoffResponsibility and expected next action.

Post-incident reviewOnly where a governance process exists.

Continuity evidenceDependency, state, owner, limitation. No RTO/RPO claims.

Review recovery

DisruptedRecoveringOperational

Recovery is confirmed by the authoritative service state, never by this page.

Vulnerability and exposure coastal landscape

Found a vulnerability?

Report via Responsible Disclosure

VULNERABILITY & EXPOSURE BOUNDARY

What we will say about exposure, and what we will not

No scanning, penetration testing, exploit validation, attack-surface management or remediation capability is claimed unless current product documentation establishes it.

AREA	SAFE PUBLIC TREATMENT	DO NOT INFER
Exposure reference	✓ Generic issue, affected scope, owner, current state	✕ Scanner coverage, asset discovery, exploitability, CVSS workflow
Assessment	✓ Approved assessment reference, only when public	✕ Continuous scanning, pentest frequency, red-team coverage
Remediation	✓ Owner, target state, exception or risk acceptance	✕ Patch automation, SLA, guaranteed closure
Responsible Disclosure	✓ The canonical vulnerability-reporting route	✕ Public vulnerability detail, bounty terms or response SLA
Penetration testing	✓ A link to an approved Zoiko Shield page, once approved	✕ Capability breadth from earlier design surfaces

Review boundary

SECURITY CONTROLS & POLICY LAYER

Controls with scope, owner, state and evidence

Plain-language objectives such as restrict, monitor, recover, review or evidence. No invented framework mapping.

Security controls snowy mountain landscape

Compliance boundary. A control state never proves that an organization or workload is compliant. That determination belongs to Regulatory Technology and Trust evidence.

Security control · CTL-114

SPECIMEN · SYNTHETIC DATA

ObjectiveRestrict administrative access

ScopeBilling service · production

OwnerPlatform security lead

StateEffective

Evidence: configuration export, reviewed 02 Oct · fresh

Exception: legacy reporting job · expires 31 DecException

Review controls

HUMAN OWNERSHIP & ESCALATION

Seven accountable people behind every security claim

Each role owns a specific part of what this page may say, and who answers when it matters.

Security / technology owner

Scope, accuracy and safe terminology

Product / platform owner

Protected scope, maturity and routes

Incident / status owner

Public incident and maintenance state

Privacy reviewer

Data-handling statements and examples

Trust / compliance reviewer

Certification wording, no overclaim

Legal / communications

Incident, disclosure and claim language

Web / SEO owner

Publishes without changing security meaning

Review ownership

Evidence trail · INC-0412

SPECIMEN · SYNTHETIC DATA