A security operations centre (SOC) platform collects logs and security signals from across an organisation, turns them into alerts, and gives analysts the workflows to investigate and respond. Building one is less about clever detection models than about getting the data in cleanly, keeping vulnerabilities on a managed lifecycle and putting trained people behind the alerts around the clock.
On this page
We built SayCure, a 24×7 SOC platform, for CryptoGen Nepal, a managed security service provider. This post explains what went into it, what we’d tell anyone planning a similar build, and where AI and automation do and don’t belong in a SOC. Everything we say about SayCure here comes from the published case study.
What is a SOC platform?
It’s the system a security team uses to watch an organisation’s infrastructure, detect threats and respond to them. At minimum it centralises logs, monitors them in real time, raises alerts, tracks vulnerabilities and records incident handling. A managed SOC adds trained analysts who work those alerts 24 hours a day.
What did the SayCure build include?
SayCure brings log management, threat monitoring and vulnerability workflows into one system, run by trained and certified analysts 24×7. Our work for CryptoGen Nepal covered IT consultancy, the SOC platform itself, managed detection and response, and vulnerability assessment and management.
- Centralised log management and parsing.
- Real-time threat monitoring and alerting.
- Vulnerability assessment, including package-level vulnerability detection.
- Vulnerability management with reporting and trends over time.
- Threat intelligence feeds and weekly updates on emerging threats.
- Rootkit detection integrations.
- Playbooks and workflows for triage, escalation and remediation.
- Periodic security awareness training for client staff.
What problem was it solving?
Organisations in Nepal and the wider region face growing threats with little in-house security capacity. The common pattern was separate tools that didn’t talk to each other, too few people who could run SIEM and SOC processes, vulnerability scans done ad hoc with no structured follow-up, and no steady supply of threat intelligence or user awareness training.
What are the main lessons for anyone building a SOC platform?
Four stand out from SayCure’s design. Put everything in one view, because split tools delay detection. Treat vulnerabilities as a lifecycle, not a scan. Keep humans in the loop for judgement calls. And define use cases with the people who run operations, not only with engineers.
1. One view beats many tools
SayCure consolidates logs, assets, vulnerabilities and compliance posture in a single place. When an analyst has to switch between four consoles to understand one alert, detection slows down. If you’re planning a build, budget most of the early effort for collecting and parsing data from every source into one model. Detection logic is only as good as the data under it.
2. Vulnerability work needs a lifecycle
A one-off scan produces a report that ages quickly. SayCure runs periodic assessments, detects vulnerable packages, prioritises findings and tracks remediation, with trend reporting so you can see whether the backlog is shrinking. Design for the follow-up, not the scan.
3. Automation supports analysts; it doesn’t replace them
SayCure is operated by trained and certified analysts 24×7. Monitoring and alerting are automated, but triage, escalation and remediation follow documented playbooks with people making the calls. That’s the right split for most organisations. Automate collection, enrichment and well-understood responses, and keep people on anything ambiguous.
4. Build use cases with operations
The SayCure use cases were curated with technology leaders and operations managers, so platform features map to real operational work. A SOC built only from an engineering wish list tends to produce alerts nobody acts on.
What results did SayCure deliver?
The case study reports qualitative results rather than published figures. Continuous monitoring and fast alerting cut mean time to detect inbound threats. Periodic assessments improved vulnerability visibility and remediation. Ongoing control monitoring strengthened compliance reporting. Documented incident handling and weekly threat updates improved operational readiness.
Where does AI fit in a SOC?
AI is most useful where volume overwhelms people: grouping and ranking alerts, summarising incidents, parsing threat intelligence written in prose and spotting unusual behaviour against a baseline. It’s least useful as an unsupervised decision-maker. Any AI component should explain why it flagged something and leave the response decision with an analyst.
- Good candidates: alert clustering and prioritisation, incident summaries, extracting indicators from threat reports, anomaly detection on user and network behaviour.
- Be careful with: fully automated containment, and any model whose output an analyst can’t trace back to evidence.
- Get right first: clean, parsed, centralised data. Without it, no model will help.
If you’re adding LLM features to security tooling, the same risks apply as anywhere else, prompt injection included. Our post on enterprise AI security practices covers the controls.
How should you plan a SOC platform build?
Start narrow. Pick the few data sources and threat scenarios that matter most, get collection and parsing working end to end, then add monitoring rules, vulnerability workflows and response playbooks. Run new detections alongside existing processes before trusting them. Expand once analysts are acting on the alerts you already produce.
Scope
List the assets, log sources and top threat scenarios. Agree with operations what a useful alert looks like.
Data collection and parsing
Centralise logs from firewalls, servers, endpoints, cloud accounts and identity systems into one normalised model.
Monitoring and alerting
Write detection rules for the agreed scenarios, add threat intelligence and tune until false positives are manageable.
Vulnerability lifecycle
Schedule assessments, track findings to remediation and report trends.
Response
Write playbooks for triage, escalation and remediation, and staff the rota that will follow them.
Review and extend
Measure detection and response times, review missed incidents and add sources and scenarios step by step.
How can Dignep help?
We build security and compliance software as well as running governance engagements. Besides SayCure, we designed and built Certifyi, an AI SaaS GRC platform. For a SOC or security platform build, a dedicated team is usually ready in 2–4 weeks. Governance and GRC engagements start with a 2–6 week scoping phase. See cybersecurity and GRC services.
If you need a ready-made managed SOC rather than a custom platform, buying a service is usually faster and cheaper than building one.
Frequently asked questions
Who built SayCure?
Dignep Group developed the SayCure platform for CryptoGen Nepal, a cybersecurity firm and managed security service provider in Nepal. More detail is on saycure.io and in our case study.
Should we build a SOC platform or buy one?
Buy if a managed SOC or an off-the-shelf SIEM covers your needs. Build if you’re a security provider offering SOC as a service, as CryptoGen Nepal is, or if you have integration or data residency requirements that products don’t meet.
Related reading: GRC software in practice.
