Tenant boundaries
Isolation is required across identity, API, storage, queues, search, evidence and customer-side components. Cross-tenant data exposure is a release blocker.
Security & trust
Control comes
before change.
Yerokom is being built as privileged enterprise infrastructure. Security claims therefore need implementation, release scope, adversarial testing and verifiable evidence—not a badge generated from a design document.
Security model
Clear boundaries. Verifiable evidence.
Security requirements span the control plane, customer-side components, connectors, release artifacts, identity, storage, queues, search, evidence and support operations. A failure in one layer cannot be treated as an isolated application bug.
Least privilege
Use scoped identity, federation and short-lived credentials where possible. Privileges should be target- and purpose-bound rather than broadly reusable.
Protected credentials
Credentials and sensitive tokens should not appear in ordinary UI, API responses, logs, exports or customer-facing documents.
Release integrity
Release requirements include review, dependency and artifact scanning, SBOM/provenance, signing, staged delivery and rejection of untrusted updates.
Customer stop paths
Customers need practical read-only, revoke and stop controls that do not depend on reaching support during a critical event.
Restoration evidence
Backups are not treated as recovery evidence until restoration is tested. Existing customer operations should remain independently usable during a Yerokom outage.
Privileged execution
A write path is a governed transaction, not a button.
Supported management actions are designed to carry scope, policy, authorization, execution evidence, after-state verification and recovery intent together.
Before action
Constrain intent.
Resolve the exact targets and desired state, evaluate prerequisites and policy, establish authorization and record what is expected to change.
- Target identity
- Current and desired state
- Policy evaluation
- Blast-radius awareness
- Artifact validation
- Bound authorization
During action
Limit execution.
Use the supported management path with bounded credentials and scope. Preserve output and failures without converting discovery capability into general-purpose write access.
- Least-privilege path
- Scope enforcement
- Rate and concurrency controls
- Canary or phased rollout where appropriate
- Execution evidence
- Explicit failure state
After action
Verify independently.
Collect resulting state through an appropriate verification path, compare it to the intended outcome, and retain recovery evidence when the result is incomplete or wrong.
- Independent after-state
- Outcome comparison
- Health validation
- Dependency validation
- Rollback / recovery path
- Evidence retention
Data handling
Know what leaves the environment, why it leaves, and how long it remains.
Inventory, telemetry, configuration, identities, execution output and support artifacts have different sensitivity. Release-specific data flows should identify purpose, location, access and retention rather than hiding everything under a generic “telemetry” label.
01MinimizeCollect only what is needed for the authorized product purpose and selected capability.
02Classify & discloseIdentify data categories, processing location, providers, sensitivity and intended use.
03Control accessBind administrative and support access to role, need, approval and auditable evidence.
04Retain deliberatelyApply stated retention and offboarding behavior with verifiable export, revocation and deletion workflows.
Customer data is not represented as available for generalized-model training without explicit authorized agreement. Release-specific AI behavior, data flows and providers must be disclosed separately where applicable.
Assurance status
Do not confuse a target control framework with issued third-party assurance.
The trust center separates engineering intent and internal evidence from external certifications or assessments. Independent claims should become public only after the relevant external work is actually complete.
Current public posture
No unsupported compliance claims.
SOC 2 reportNo issued report is claimed on this website.
Not claimed
ISO certificationNo issued ISO certification is claimed on this website.
Not claimed
FedRAMP authorizationNo FedRAMP authorization is claimed on this website.
Not claimed
Independent penetration testA completed external test is not claimed until independently performed and available within release scope.
Evidence required
Evaluation scope
Security expectations should be explicit before connection.
Evaluation scope should identify data flows, integrations, management permissions and release-specific controls before access expands beyond read-only discovery.
Website and procurement
Current operational controls—not certification badges.
The public site enforces HTTPS and canonical URLs. Enquiries are validated server-side, protected against forged requests and written to a private company inbox before receipt. Price inputs are recalculated at intake; browser totals are not accepted as an offer.
These are website controls. They do not establish the security, integration coverage or customer readiness of a product release.
Review the procurement packet