20 November 2025

Things to consider when creating a SIEM Specification

When deploying a new SIEM Solution there can feel like an overwhelming number of factors, configurations and considerations that need to be accounted for to ensure the final platform is fit for purpose and provides adequate visibility across the cyber estate. In order to assist with a new SIEM deployment, a SIEM Specification can be created, this will work as a both a design document and a blueprint for the solution. Apto’s SIEM Specification follows our tried and tested methodology of Discover, Design, Deploy and Operate; these tenants govern both how we architect the SIEM, in addition to how we gather the information from the client that is required.

Discover our methodology Further

Whilst a SIEM specification will have numerous sections and subsections, in this blog we will highlight what we believe the main 5 components of a robust SIEM Specification are, along with providing a high level outline of what each section should contain and how it help guide the creation of a resilient and scalable SIEM, which can be used for solutions from Splunk to Next Gen SIEM.

1. Solution Specification

A solution specification is a key step for any SIEM deployment, however it is critical for any on-premise deployment as this section will be used to architect everything from data flow and log collection, through to the Hardware and Network requirements for each component of the SIEM.

Primarily we will break this section down into two sub-sections, the service decomposition and the product
specification. The service decomposition serves as a way to break down, at a high level, what the SIEM will be used for, this can have some level of consideration for what data will feed into the SIEM however the main goal of this section is a non-technical break down of the capability the platforms will offer, in a manner any non-technical stakeholder can understand.

The product specification section will be a lower-level technical breakdown of how the solution will be deployed, this will often include the low-level architectural diagrams, as well as the Hardware, Software and Network requirements for the solution.

2. Framework, Security Strategy, and Compliance Needs

This section of the Specification will focus on how the SIEM will fit into an organisations wider compliance needs and security postures, we break this down into 4 key areas, Best Practice, Regulatory, Security, and Industry frameworks, these will vary from being mandatory frameworks your organisations must adhere to, to voluntary frameworks used to help assess and grow your security posture. Whilst this is not an exhaustive list of all the possible compliance requirements, as a general rule this will cover most basic needs, and equally you may find your organisation has no need to fill all these requirements.

A brief breakdown of what we mean by each compliance area is as follows; Best Practice frameworks refer to any vendor specific suggestions that will be used when designing and deploying the system, one example is Splunk’s Professional Services Vest Practice framework, A Regulatory framework refers to legal requirements that an organisation must adhere to, such as the Telecommunications Security Act, or any act that non-compliance will lead to fines, limits, or business closure by a regulatory body. Security frameworks refer to any frameworks that are being used to design, assess, and manage the security posture of the business such as the MITRE ATT&CK or NIST CSF. Finally, industry frameworks will refer to any frameworks that are followed by a specific industry but are not enforced by any legal body and are instead guidelines for safe operation, these can often be bespoke frameworks the organisation themselves have created.

3. Data Structure

This section will include the design for the data that will be ingested into the SIEM platform, this should be as
detailed as possible as it can be a very useful reference point to catalogue data within the platform and can enable easier maintaining and expansion of the SIEM after it has been fully deployed.

The contents of this section will vary depending on the SIEM product being deployed, however at a high level this should document all the data feeds that will hit the SIEM, any special requirements to collect this data, how this data will be categorised and stored within the SIEM and finally how long the data should be retained for within the platform. This section can be very useful for working out a rough guide for how much data will be ingested and stored in the platform, which can drive the decision on how much storage is required for the solution.

4. Security Posture

This section will be used to outline how the SIEM will support and expand an organisations security posture, it will cover the Detections that will be deployed, any Threat Intelligence that may be used, as well as any SOAR features that may be used. This section will also consider the security of the SIEM platform itself, for example it will consider how user access the SIEM, whether this be LDAP/SAML or local log ins, and the details of how this will work, as well as what roles will be created within the SIEM, and how users/user groups will be mapped to these roles. This section can scale significantly based on the quantity of detective use cases that an organisation needs, in addition to how complex the SOAR requirements are for the solution.

5. Operational Model

Finally, a section on the Operational Model is key for a robust SIEM deployment, this section will outline who will be using the SIEM, what they will be using it for, and how they will achieve what they need through the SIEM. This is key as it ensures all the stakeholders for the SIEM are identified and can provide a pre-emptive value assessment for the platform as it outlines how many users will interact with the platform, the value it offers these stakeholders, and the capabilities it provides.

This section can also be useful for assigning ownership and accountability for the different components of the SIEM, this can be useful for preventing a scenario where ownership of a Detection, SIEM component or an alert is ambiguous which leads to it not being maintained or acted upon in the event that there is a failure of infrastructure or a security detection triggers but is not investigated.

Conclusion

In summary a SIEM spec is a tool that can streamline the design and deployment of a new SIEM solution, in
addition to ensuring the long term maintenance of the platform is as easy as possible, as well as providing a single source of truth for the deployment which can be used as a reference point for all SIEM users, should they have any queries about the inner workings of the solution.

click here to book a call!