Security that adapts to your environment,
not the other way around.
Every VOC workspace is designed on a defense-in-depth baseline — identity, encryption, auditability, and governed AI — then aligned during technical discovery with the standards your organization already operates under.
“Security architecture is configured according to the client's hosting environment, regulatory requirements, risk profile, and internal IT policies.”
This is the operating principle behind every VOC deployment. We do not force a one-size-fits-all posture — we implement the controls your environment requires.
Designed for your security environment
A VOC workspace is the operational layer above your existing systems — so it deploys where your security organization wants it to run. The final security architecture is defined during technical discovery and aligned with the customer's infrastructure, policies, regulatory requirements, and risk profile.
Customer Azure
The workspace deploys into your own Azure tenant. Entra ID, Key Vault, VNets, and your cloud governance apply directly; VOC builds and maintains the application within them.
Customer AWS
The workspace runs in your own AWS account under your IAM policies, KMS keys, and VPC design — your organization retains account-level control throughout.
VOC-managed cloud
VOC provisions and operates a dedicated, isolated environment for your workspace — typically the fastest deployment path, with customer-managed keys available as an option.
Private cloud
The workspace runs on private-cloud or on-premises infrastructure you operate, entirely inside your network perimeter, with every infrastructure control in your hands.
Hybrid
Components can be split across environments — for example, the application in your cloud tenant with specific data stores kept on-premises — where your policies require it.
Not sure which fits? That is exactly what technical discovery is for — the deployment environment is selected with your IT and security teams, not for them.
Discuss Your OperationSecurity capabilities across the stack
Four control domains cover every VOC workspace — from the identity layer through the development pipeline.
Role-based access control
Permissions are scoped by role, module, and record type, so every user sees exactly what their function requires — nothing more.
SSO via SAML & OIDC
Workspaces integrate with your identity provider — Entra ID, Okta, Ping, and other SAML 2.0 or OIDC platforms — for centralized sign-on.
Multi-factor authentication
MFA is enforced through your identity provider or natively in the workspace, with support for authenticator apps and hardware keys.
Least-privilege defaults
New accounts start with minimal rights. Elevated access is granted explicitly, time-bounded where required, and visible in the audit trail.
Provisioning & deprovisioning
User lifecycle can follow your directory: joiners are provisioned by role, and leavers lose access the moment they are deactivated upstream.
Session & token controls
Configurable session timeouts, token expiry, and concurrent-session limits align workspace behavior with your access policies.
Encryption in transit
All traffic between clients, services, and integrations is encrypted with TLS 1.2 or higher; legacy protocols are disabled by default.
Encryption at rest
Databases, file stores, and backups are encrypted at rest with AES-256, using platform-managed or customer-managed keys.
Data retention controls
Retention and deletion schedules are configurable per record class, so operational data lifecycles match your internal policies.
Data residency options
Workspaces deploy to the cloud region — or the client-controlled environment — that satisfies your residency and sovereignty requirements.
Backups & restore
Automated, encrypted backups run on a defined schedule, with restore procedures tested as part of each deployment's runbook.
Data segregation
Each client's workspace runs in its own isolated environment and data store — there is no shared multi-tenant database.
Audit trails
Every sign-in, permission change, record update, and AI interaction is logged with actor, timestamp, and context — exportable for review.
Logging & monitoring
Application and infrastructure telemetry feed centralized monitoring with alerting on anomalous access and availability events.
Environment separation
Development, staging, and production run as separate environments with independent credentials and promotion gates between them.
Disaster recovery approach
Each deployment defines recovery time and recovery point objectives with the client, backed by tested backup-and-restore procedures.
Vulnerability management
Continuous scanning of infrastructure and dependencies, with remediation prioritized by severity and tracked to closure.
Incident response process
A documented process covers detection, containment, client notification, and post-incident review with corrective actions.
Secure SDLC
Security requirements, threat modeling, and automated checks are built into the delivery lifecycle — not bolted on before go-live.
Code review
Every change is peer-reviewed before merge, with security-sensitive paths — auth, data access, integrations — receiving added scrutiny.
Dependency scanning
Third-party packages are scanned continuously for known vulnerabilities, with patch windows defined by severity.
API security
APIs enforce authentication, per-role authorization, rate limiting, and input validation, with schema-level contracts for integrations.
Penetration-test readiness
Workspaces are designed to support independent testing; clients may commission penetration tests, and findings are remediated on agreed timelines.
Secrets management
Credentials, API keys, and connection strings live in managed vaults — never in code, configuration files, or version control.
Roadmap — not current certifications
We tell you exactly where we are. VOC does not currently hold formal certifications; the items below are planned or on our roadmap, and we build to their control expectations today.
Security capability baseline
Identity, encryption, audit, and secure-SDLC controls described on this page are implemented in current deployments.
SOC 2 Type I readiness assessment
An independent readiness assessment against the SOC 2 Trust Services Criteria — planned, not yet completed.
SOC 2 Type II
A full observation-period audit is on our roadmap following Type I readiness. No SOC 2 report exists today.
ISO 27001 alignment review
A structured review of our ISMS practices against ISO 27001 controls — roadmap item; we do not claim ISO 27001 certification.
Regulatory requirements, per engagement
If your organization operates under HIPAA, GDPR, GLBA, or sector-specific frameworks, those requirements are scoped during discovery and reflected in the workspace's architecture, hosting model, and contractual terms.
Security posture by hosting model
Where your workspace runs determines who controls each layer. Select a model to see how responsibility for identity, keys, network, and backups is assigned.
| Control area | Controlled by | How it works |
|---|
All four models retain the same application-layer controls: RBAC, audit trails, encryption in transit and at rest, and governed AI usage.
Can your IT team control it?
Yes — that is the design intent, not a concession. A VOC workspace is designed to sit inside your IT organization's governance, not alongside it.
Customer-controlled identity
Your identity provider governs sign-on, MFA, and lifecycle — users are created, changed, and revoked in your directory, not in a vendor console.
Permissions mapped to your org
Roles and record-level access mirror your actual org structure and approval chains — configured with your administrators, adjustable without code changes.
IT at every architecture gate
Your IT and security teams participate in the executive gates at architecture, prototype, and go-live — nothing reaches production without their review.
Client-hosted options
Where policy demands it, the workspace runs in your tenant, account, or data center — and standing VOC access can be reduced to supervised sessions or removed.
Security FAQs
The questions security and IT teams ask first — answered directly.
Bring your security requirements.
We'll design to them.
Walk through identity, hosting, and governance decisions with our team — typically starting with one department, expanding when the value is proven.