What is HLD
HLD stands for High-Level Design, that is, a high-level project. In information security, this is an architectural document that explains how the target information protection system should be structured: what contours we protect, where the trust boundaries are, what classes of information security are needed, how zones are divided, what data flows are critical and how the solution is built into the existing IT landscape.
HLD should not turn into an abstract picture. Its goal is to give CIOs, CISOs, architects, system owners, procurement and operations a common understanding of the future path before procurement and implementation begin. At this level, principles, dependencies, restrictions, target scheme and solutions are fixed, which cannot then be changed imperceptibly at the configuration stage.
Place of HLD in Enterprise architecture
In an enterprise environment, HLD is located between information security strategy and detailed technical design. It links business processes, regulatory requirements, threat model, IT architecture, network segmentation, IAM/PAM, SOC/SIEM, DevSecOps, ERP, DWH, cloud, branch, remote access and operational processes.
For a large company, HLD is useful as an architectural contract: it shows which systems are included in the scope, which risks are covered, which solutions must be compatible, which integrations are required, where pilots are needed and which changes will affect users. Such a document helps to avoid a situation where information security systems are purchased, but do not work together, do not produce the necessary events in the SIEM, break business processes, or do not pass acceptance by operations.
| Enterprise layer | What does HLD record? |
|---|---|
| Business and regulation | Critical processes, applicable requirements, ISPD, CII, GIS, personal data, trade secrets, audit and inspection requirements. |
| IT landscape | Systems, loops, networks, branches, clouds, integrations, access channels, data exchange points and infrastructure dependencies. |
| Information security architecture | Security zones, security information classes, access model, logging, monitoring, response, cryptography, endpoints, web/API and data protection. |
| Operation | Roles, change processes, monitoring requirements, SLA/OLA, maintenance, redundancy, updates and performance monitoring. |
What is LLD
LLD stands for Low-Level Design, that is, a low-level design or a detailed technical design. If HLD answers the question “how the environment should be arranged,” then LLD answers the question “how exactly it will be assembled, configured, connected and accepted.”
LLD includes specific components, versions, network interfaces, addressing, interconnection rules, integration with directories, SIEM, ITSM, PAM, scanners, EDR/XDR, WAF, DLP, CIPF, access policies, logs and backup. For the implementation team, the LLD becomes a working instruction, for operations - future documentation, and for acceptance - the basis for checking that the solution really matches the architecture.
Place of LLD in Enterprise architecture
LLD lives closer to implementation and production operations. It translates architectural decisions into configurations, rules, parameters, checklists, migration steps and acceptance criteria. In the enterprise landscape, this is especially important because one setting can affect the network, domain structure, business application, monitoring, help desk and regulatory reporting.
A good LLD goes beyond a list of product settings. It describes how the solution would exist in a real operating model: who administers the policies, who receives events, how exceptions are handled, how rules are updated, where logs are stored, how rollback is performed, what is considered a successful acceptance, and what metrics show that the protection is working.
| Practical layer | What does LLD record? |
|---|---|
| Components | Servers, agents, sensors, gateways, policies, versions, roles, accounts, certificates and dependencies. |
| Network and Integrations | IP/FQDN, ports, routes, firewall rules, API, syslog, webhooks, queues, connection to AD/LDAP, SIEM, ITSM and storage. |
| Information security settings | Access policies, exceptions, scan profiles, use cases, correlation rules, logging levels, retention and response rules. |
| Acceptance and operation | Step-by-step implementation plan, tests, negative scenarios, rollback, runbook, administrator instructions and criteria for transferring to support. |
HLD and LLD: comparison
HLD and LLD do not compete with each other. These are two levels of one design: HLD is needed to coordinate the target architecture and management decisions, LLD is needed to safely and verifiably implement them in the infrastructure.
| Criterion | HLD / High-Level Design | LLD / Low-Level Design |
|---|---|---|
| The main question | How should the target security architecture be designed? | How exactly to implement it, configure it and accept it? |
| Audience | CIO, CISO, enterprise architects, system owners, procurement, project office. | Implementation engineers, administrators, operations, SOC, DevOps/DevSecOps, testing. |
| Level of detail | Contours, zones, solution classes, principles, flows, dependencies and constraints. | Components, parameters, addresses, rules, policies, integrations, tests and runbooks. |
| Risk without a document | They bought the wrong thing, did not take into account the dependencies, and ended up with an architecture conflict and an expensive rework. | We implemented it differently in different teams, lost the settings, and were unable to make and support a decision. |
| Result | Consistent target architecture and project framework. | Working technical design for implementation and operation. |
When are HLD/LLD really needed?
HLD and LLD are especially important when the project affects several systems, teams and requirements: implementation of information security systems, modernization of the perimeter, protection of ISPDn, CII or GIS, launch of SOC/SIEM/SOAR, PAM/IDM, DLP, WAF, EDR/XDR, CIPF, DevSecOps, API protection, AI environment, branch network or critical integrations.
If the project is small, you can start with a lightweight HLD and a short LLD. If the loop is regulated, critical, or distributed, design savings are almost always returned in rework: policy conflicts, incomplete SIEM events, access errors, unaccepted exceptions, manual workarounds, and disputes between IT, security, and contractors.
How RESTART conducts design
Scope and examination
We fix the business task, regulators, boundaries of the environment, systems, networks, roles, data, current information security systems, restrictions and operational pain points.
HLD architecture
We describe the target protection model, zones, solution classes, flows, integrations, infrastructure requirements, risks and options for architectural solutions.
LLD detailing
We prepare settings, interaction schemes, access matrices, rules, log requirements, test scenarios, implementation plan and rollback.
Reception and transfer
We agree on readiness criteria, conduct reviews with IT/IS/operations, prepare runbooks, implementation backlogs and recommendations for development.
Deliverables
- HLD document with target architecture, zones, flows, information security classes, dependencies and architectural solutions;
- LLD document with components, settings, integrations, network rules, access matrices, logging and tests;
- architectural diagrams: contours, segmentation, data flows, administration channels, events in SIEM/SOC, integration with IAM/PAM/ITSM;
- requirements matrix: regulations, threat model, business risks, operational requirements and acceptance criteria;
- implementation roadmap: stages, dependencies, pilots, rollback, migration, training, transfer to maintenance and development backlog.
Link to Implementation and Operations
Design makes sense only when it can be used to implement and maintain a system. Therefore, RESTART connects HLD/LLD with vendor selection, pilot, procurement, implementation, policy configuration, integration with SIEM/SOC, administrator training and commissioning.
After design, the team can move on to the implementation of information protection systems, supply of licenses, configuration, testing, development of regulations, trial operation and support. If the customer already has part of the solutions, HLD/LLD helps not to repurchase the entire stack, but to build new security measures into the existing architecture.
For endpoint projects, HLD/LLD captures device groups, EPP/EDR/XDR policies, exceptions, integrations with SIEM/SOAR, PAM/IDM and ITSM, and then is transferred to implementation of Endpoint Security.
HLD/LLD testing in the laboratory
It is better to check some architectural decisions before the final LLD: WAF rules, event collection in SIEM, agent load, PAM access rights, network routes, CIPF and failure scenarios. The Information Security Lab turns design assumptions into verified constraints and requirements for industrial implementation.
Frequently asked questions
Is it possible to do LLD without HLD?
Technically it is possible, but in enterprise projects it is risky: the team will quickly go into product settings without agreeing on areas, boundaries of responsibility, data flows and operational requirements.
Is HLD just a schema?
No. The blueprint is important, but the HLD also captures the architectural decisions, requirements, dependencies, constraints, security classes, risks, integration principles, and readiness criteria.
Who should agree on HLD and LLD?
HLDs are typically agreed upon by the CISO, IT architecture, system owners, and operations. LLD additionally undergoes engineering review from administrators, SOC, DevOps/DevSecOps and implementation team.
What is more important to check: HLD or LLD?
Both levels are important for verification. HLD demonstrates the validity of the security architecture and controls, LLD demonstrates that the controls are implemented in a specific, verifiable and controllable manner.
Can documents be used for procurement?
Yes. The HLD helps define requirements for solution classes and integrations, while the LLD clarifies the scope of implementation, contractor work, acceptance criteria, and operational limitations.
What to do if information security has already been purchased?
You can start with an architectural review: check which solutions already cover risks, where there is duplication, which integrations are not implemented and what needs to be adjusted to the industrial model.
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.
