Visible ownership
Before launch, we define Virtek, customer and supplier boundaries, owners, access, change and escalation paths.
Trust · security · transparency
The Virtek Trust Center brings together our approach to data protection, access, software delivery, operations and incident response. It distinguishes enduring engineering practices from controls designed and contracted for a specific system.
Open trust framework · evolves with our practicesFoundation of trust
We treat security as a property of the whole system: people, architecture, processes and operations. The control set follows the data, threats, criticality and deployment model.
Before launch, we define Virtek, customer and supplier boundaries, owners, access, change and escalation paths.
Permissions follow role and task, are reviewed as responsibilities change, and privileged activity receives dedicated control.
Architecture, settings, changes, events, recovery and validation results are documented to the depth agreed for the project.
Engineering practices
This catalogue covers the domains considered across design, implementation and support. The depth of each control is set through assessment and threat modelling.
Roles, multi-factor authentication, account lifecycle, service access and privileged control.
Baseline practiceClassification, minimisation, encryption, backups, retention, deletion and deployment location.
Designed for the systemEnvironment separation, secrets and dependency management, change review, logging and controlled releases.
Baseline practiceSegmentation, redundancy, resource monitoring, recovery and failure-scenario validation.
Designed for the systemAgreed logging scope, critical-event monitoring, correlation, retention and access to evidence.
Designed for the systemInventory, severity assessment, remediation, exceptions, updates and result verification.
Baseline practiceComponent origin, support lifecycle, updates, compatibility and supply-chain risks are assessed.
Designed for the systemEvent classification, containment, communication, restoration, cause analysis and preventive action.
Defined by procedureShared responsibility
The same service creates different roles in cloud, customer-site and hybrid deployments. This matrix shows the principle; the exact allocation belongs in project and contract documents.
Virtek responsibilityDesign the target environment and recommend controls.
Customer responsibilityProvide process requirements and accept residual risk.
Virtek responsibilityDeliver, configure and operate the agreed scope.
Customer responsibilityProvide physical, organisational and network conditions in the customer domain.
Virtek responsibilityConfigure mechanisms, roles and controls in agreed systems.
Customer responsibilityAppoint owners, approve users and report role changes promptly.
Virtek responsibilityImplement agreed protection, backup and deletion mechanisms.
Customer responsibilityDefine data categories, legal basis, retention and permitted processing locations.
Virtek responsibilityObserve the agreed scope, diagnose and escalate events.
Customer responsibilityProvide contacts, access and decisions requiring system-owner authority.
Virtek responsibilityDeliver through a controlled process and record outcomes.
Customer responsibilityApprove impact, maintenance windows, priorities and business acceptance criteria.
Deployment control
One deployment model does not fit every workload. We select the environment around data, connectivity, performance, control and continuity requirements.
Managed service and data deployment on our infrastructure with agreed redundancy, access and support.
On-premises infrastructure and AI models remain inside the organisation's controlled perimeter; Virtek designs, deploys and supports the solution.
Critical data and components are distributed under explicit exchange, access, backup and recovery rules.
Incident lifecycle
Response is built around maintaining control: understand impact quickly, contain progression and restore the business process safely.
Receive a signal from monitoring, a user, an engineer or an external source and preserve the initial evidence.
Determine impact, severity and boundaries; take action to reduce further damage.
Use the agreed channel to share what is known, what is being done and which decision or access is required.
Return the function, verify integrity and stability, and observe the system after recovery.
Record timeline, cause and corrective action; turn material findings into architecture or process changes.
Transparency and documents
Public documents explain how the website and company operate. Project architectures, threat models, test protocols and restricted procedures are delivered within the relevant engagement and protected by contract where appropriate.
What personal data the website processes, why, on which basis and how data-subject rights can be exercised.
Registration, security, document exchange and use of the client-account functions.
Control essential site technologies and consent to Yandex Metrica analytics cookies.
Official company information, IT activities, pricing principles and rights to the solutions provided.
Open resource↗Open the official register of accredited Russian IT companies. Use TIN 0274922889 for verification.
Open resource↗A single channel for requests, technical questions, security events and a complete interaction history.
Open resource↗Report a concern
Do not publish technical details or send passwords and keys in an open message. Create a support request marked “Information Security” or email info@virtek.pro. We will acknowledge it and arrange a secure channel for evidence.
Open a protected request↗This Trust Center describes Virtek's general approach. It is not a certificate, public offer or universal assurance for a specific information system. Architecture, applicable legal requirements, controls, service levels, responsibilities and notification procedures are defined for each project in its contract and project documentation.
Validate before deployment
We will assess critical processes and data, define shared responsibility and propose a security architecture that can be tested.
Discuss security↗