When protecting GIS becomes a management task
GIS is not just a portal or a database that needs to be “closed by order.” Typically, around a government information system there are users, departmental processes, integrations, personal data, exchange with external services, contractors, operation, procurement and managerial responsibilities. Therefore, protecting GIS quickly becomes a task at the CISO, CIO, system owner, legal, procurement, and operations levels.
The page is useful for government customers, subordinate organizations, state unitary enterprises/state budgetary institutions, large contractors and enterprise companies that create, modernize or maintain state and sub-state IT environments. The main value is understanding how to turn requirements into architecture, documents, implemented security controls and managed operations, rather than into a separate folder for review.
Terms without fog
| Term | Decoding and meaning |
|---|---|
| GIS | State information system. In essence, this is an information system created or used to perform government functions, provide services, maintain registers, interdepartmental exchange or other publicly significant processes. For a project, it is important to define not only the name of the GIS, but also the boundaries, owner, operator, data, integrations and mode of operation. |
| Operator and owner of information | Roles that determine responsibilities, access, contracts with contractors, information processing procedures, document requirements and security decisions. |
| SZI | Information security tools: classes of technical solutions that help implement security measures - access control, antivirus/EDR, firewalls, WAF, DLP, SIEM, vulnerability scanners, virtualization protection and other components. |
| CIPF | Means of cryptographic information protection. They are used where cryptographic mechanisms are needed: secure channels, VPN, electronic signature, GOST TLS, HSM/PKI and related scenarios. Requirements for CIPF must be checked separately, taking into account the FSB, architecture and specific exchange. |
| ISPDn and PDn | ISPDn - personal data information system, PDn - personal data. If a GIS processes personal data, the protection loop should be linked to Federal Law No. 152-FZ and the requirements for ISPD, and not considered in isolation. |
| CII | Critical information infrastructure. If the system affects significant processes in the areas of Federal Law No. 187-FZ, separate logic for categorization, protection of a significant object, monitoring and response may be required. |
| HLD and LLD | HLD, High-Level Design, is a high-level architectural project: zones, flows, solution classes, requirements and dependencies. LLD, Low-Level Design, is a detailed project: components, settings, rules, integrations, tests and acceptance. For GIS, these documents help connect regulations with real infrastructure. |
| SIEM, SOAR, SGRC | SIEM collects and correlates security events, SOAR automates responses, SGRC helps manage requirements, risks, controls, exceptions and evidence. For GIS, these are not “fancy acronyms”, but a way to make operation verifiable. |
Russian outline of requirements
Securing a GIS begins with the legal and architectural qualification of the system. Basic Law on Information and Data Protection - 149-FZ. Technical and organizational requirements for information protection in GIS and information systems of government bodies, state unitary enterprises and government agencies today need to be checked against by order of the FSTEC of Russia No. 117 of 04/11/2025. FSTEC Order No. 17 may appear in old GIS documents, but for new work it is important to check the current regulatory framework and not mechanically transfer old templates.
If the GIS contains personal data, it connects Federal Law No. 152-FZ And FSTEC order No. 21 according to ISPDn. If the system is associated with significant processes of critical information infrastructure, the applicability must be checked separately Federal Law No. 187-FZ and requirements for CII. RESTART does not promise “site compliance”: the final set of requirements, classes of measures and documents is determined only after examining a specific environment.
| environment | What needs to be determined | What is often forgotten |
|---|---|---|
| Boundaries of GIS | Systems, subsystems, integrations, operating environment, test and backup environments, contractors, exchange channels. | Test benches, service accounts, uploads, integration buses and external APIs. |
| Data | Types of information, personal data, proprietary information, documents, journals, archives and storage periods. | Data in logs, BI showcases, reports, backups, dev/test and file sharing. |
| Protection measures | Organizational and technical measures, information security/information protection system, access, logs, response, backup, change control. | Operational roles, SLA, administration regulations, monitoring and evidence of implementation of measures. |
| Documents and evidence pack | Threat model, design solutions, regulations, access matrices, protocols, logs, acts, instructions and development plan. | Linking documents with actual settings and responsible process owners. |
Where does a project usually break down?
Borders not defined
The team protects the “system as a whole”, but does not record which servers, integrations, stands, APIs, accounts and contractors are included in the loop.
Documents live separately
There is a threat model and regulations, but they do not coincide with the network diagram, roles, logs, actual security information settings and the change process.
Procurement ahead of architecture
First, products are purchased, and only then it turns out that they do not cover the required class of measures, conflict with the infrastructure, or are too heavy to operate.
Operation not designed
After implementation, it is not clear who analyzes events, updates rules, maintains exceptions, reviews access rights and collects evidence for verification.
How RESTART works
Survey
We record the system, owners, data, integrations, sites, contractors, documents, current information security systems, network flows and operating restrictions.
Requirements and threat model
We determine applicable standards, classes of requirements, threats, violators, critical scenarios, gaps and elimination priorities.
HLD/LLD
We design the target security architecture, zones, flows, information security/cryptographic information security classes, integration with SIEM/SOAR/SGRC, roles, logs and acceptance criteria.
Implementation
We select products, conduct a pilot, configure security tools, integrate with the infrastructure, prepare documents and transfer them to trial operation.
Operation and development
We help build regulations, change control, monitoring, evidence pack, team training and a roadmap for the development of the environment after launch.
World practices and benchmarks
The international framework does not replace Russian GIS requirements, but helps to speak to management and architects in the language of maturity, risks and operational sustainability.
| Landmark | How we use it in GIS projects |
|---|---|
| NIST Cybersecurity Framework 2.0 | We use as a management framework: governance, asset identification, protection, detection, response, recovery and the connection of cyber risk with business risk. |
| NIST SP 800-53 Rev. 5 | We take it as an international catalog of controls for architectural thinking: access control, audit and accountability, configuration management, incident response, contingency planning and privacy controls. |
| NIST SP 800-207 Zero Trust Architecture | We use it as a guideline for rejecting implicit trust in the network: access by role, context, device, segment, logs and verifiable policies. |
| CIS Controls v8.1 | Useful for practical prioritization: asset inventory, vulnerability, configuration, access, log and response management. |
| Verizon DBIR And IBM Cost of a Data Breach | We use it as an external language to talk about risks: incidents, vulnerabilities, identities, third parties, cost of downtime, speed of detection and the impact of governance on the cost of an error. |
How AI Helps Protect GIS
AI should not automatically make regulatory decisions, change access policies, or “give compliance.” But in GIS, it can remove the heavy manual workload: quickly search for requirements in documents, compare measures and actual settings, prepare draft evidence packs, explain discrepancies, summarize logs, help with security questionnaires and prompt system owners what needs to be clarified.
For such scenarios, RESTART designs a secure AI loop: approved sources, RAG on internal documents, access rights, request logs, human review, masking of sensitive data and a ban on the use of proprietary information in external services without an agreed upon architecture.
What do businesses and government customers get?
| Result | What is changing in practice |
|---|---|
| Clear boundaries of responsibility | You can see who the owner of the system is, who the operator is, where the contractor’s zone is, what data and integrations are included in the environment, what exceptions need to be closed. |
| A project instead of a set of requirements | The requirements of FSTEC, Federal Law No. 152-FZ, CII, if applicable, and internal policies are turned into architecture, settings, documents and an implementation plan. |
| Less rework | Information protection and information protection systems are selected according to architecture, threats, operation and procurement, and are not purchased in advance according to a general formula. |
| Readiness for inspection and support | Evidence pack, logs, regulations, roles and control procedures are maintained after the project, and are not collected in an emergency mode. |
| Accelerating modernization | New integrations, AI scenarios, BI showcases, personal accounts and exchanges with departments can be launched with pre-considered information security restrictions. |
Result Artifacts
- GIS map: systems, subsystems, data, integrations, roles, sites, contractors and environments;
- list of applicable requirements and gap analysis for documents, architecture and operation;
- threat model or threat model requirements outline if the full document is included in the next stage;
- HLD/LLD for information security system: zones, flows, classes of information security/information security information, integrations, logs and acceptance criteria;
- specification for procurement, pilot or implementation of protective equipment;
- a package of regulations, access matrices, instructions, protocols and evidence pack;
- roadmap: quick measures, design work, implementation, trial operation, maintenance and development.
First practical step
It is rational to start with a short diagnostic for 10-15 working days: collect GIS boundaries, owners, documents, architecture, access rights, integrations, current information security information, personal data and related requirements. After this, you can make a management decision: is a full project of the information protection system, updating of documentation, product implementation, certification training, SGRC environment or modernization roadmap necessary?
If the system is already in commercial operation, diagnostics help not to stop work, but to prioritize changes: what is critical to close quickly, what can be included in the development plan, what requires procurement, and what is resolved organizationally.
Frequently asked questions
Are GIS and ISPD the same thing?
No. GIS - state information system, ISPDn - personal data information system. One system can simultaneously be a GIS and process personal data, then the requirements need to be linked.
Is it possible to use old documents under Order No. 17?
They can be used as source material, but new work must be checked against the current regulatory framework, including FSTEC Order No. 117 of 04/11/2025 and applicable related requirements.
Is RESTART implementing information security information or just preparing documents?
We cover both layers: survey, requirements, HLD/LLD, documents, selection of solutions, pilot, implementation, configuration, integration and commissioning.
Do you need a SIEM for GIS?
Not always as a first step, but logging, monitoring and response are almost always needed. SIEM/SOAR/SGRC are considered after the survey: what events are there, who is responding, what reports and evidence are needed.
Is it possible to start without a large purchase?
Yes. A diagnostic and architectural session helps you first understand gaps, priorities and requirements, and only then select products and budget.
Can AI be connected to GIS documents?
It is possible only after designing a safe mode: sources, rights, logs, masking, bans on external transmission and mandatory human review for regulatory conclusions.
Let's discuss your environment
Describe the task, current systems, constraints, and expected results. We will offer a practical first step: diagnostics, pilot, audit, roadmap or project team.
