SOC Architecture Blueprint for Government Agencies

A security operations center (SOC) for a government agency is the team, process, and technology that continuously monitors the agency's systems, detects and analyzes cyber threats, and responds under a clear mandate. This special report is a vendor-neutral blueprint for Thai government agencies: what the Cybersecurity Act requires and does not require, a six-layer reference architecture, operating model choices, staffing arithmetic, a phased roadmap, and what to put in a TOR. It is a planning guide, not legal advice or an official standard.

Start from the legal duties

The Cybersecurity Act B.E. 2562 (2019) is the legal anchor. The points below are taken from an unofficial English translation of the Act, so check the Thai text for any formal use.

• Section 44: government agencies, supervising or regulating organizations, and organizations of Critical Information Infrastructure (CII) must prepare a code of practice and standard framework, including at least a plan for risk examination and assessment at least once per year and a plan for coping with cyber threats
• Section 45: the same organizations must prevent, cope with, and mitigate cyber threat risks in line with their code of practice, and the Office (the National Cyber Security Agency, NCSA) may assist on request
• Section 46: they must notify the Office of the names of executive and operational officials for cybersecurity coordination
• Section 58: when a cyber threat exists or may exist for a system under a government agency's or CII's responsibility, it must examine its data and systems, and if a threat is confirmed, prevent, cope with, and mitigate it per the code of practice and notify the Office and its supervising or regulating organization without delay
• For designated CII only (Section 49 lists eight aspects, such as banking and finance, energy, and public health): an annual risk assessment and cybersecurity examination with a summary report to the Office within 30 days (Section 54), a mechanism to monitor threats and participation in readiness assessments (Section 56), and reporting of significant threats (Section 57)

Two takeaways. First, the Act does not mention a SOC or prescribe an architecture. The monitoring mechanism in Section 56 and the duty to examine and respond in Section 58 are the hooks, so the SOC design is your decision, guided by your code of practice and the standards your regulator sets. Second, most agencies are covered by Sections 44 to 46 and 58, while Sections 54 to 57 apply to designated CII. "Without delay" has no number in the Act; the CRC may prescribe reporting criteria (Section 57), so check the current notifications from NCSA.

A reference architecture in six layers

Think of the SOC as six layers, each with a named owner. A gap in one layer weakens the rest.

• 1. Mandate and governance: a charter signed by the head of the agency, a defined scope (which systems and units the SOC serves), authority to isolate and block, an escalation path to executives, and a link to the code of practice
• 2. Data sources: identity (directory and single sign-on), endpoints (EDR), network (firewall, proxy, DNS, NDR), servers and applications, cloud and SaaS audit logs, email security, and the asset inventory and vulnerability scanner. Prioritize by risk rather than ingesting everything
• 3. Collection and storage: collectors, normalization (open schemas such as OCSF help avoid lock-in), reliable time synchronization, tamper-resistant storage, hot, warm, and cold retention tiers, and a policy on where logs may be stored
• 4. Detection and analytics: SIEM rules and analytics, endpoint and identity detections, threat intelligence, and use cases mapped to MITRE ATT&CK, maintained through a write, test, tune, and retire cycle
• 5. Response and automation: case management, playbooks, automation for repetitive steps, authority for containment, evidence handling, and a working link to IT operations for patches and changes
• 6. Reporting and improvement: severity-based reporting to management, notification to NCSA and the regulator when required, metrics such as MTTD and MTTR, lessons learned, and regular exercises

The SOC's own tools are a high-value target. Keep the SOC management network separate, require strong MFA and privileged access controls for analysts and administrators, and back up detection content. For tool choices, see SIEM, SOAR and XDR Compared: Strengths and Limits and Zero Trust Architecture: Components and Roadmap.

Choose an operating model

• In-house: the most control and the deepest knowledge of the agency, but hiring and keeping staff for 24x7 coverage is hard and costly
• Outsourced (MSSP or MDR): faster to start and covers all hours, but needs a strong contract, clear rules on data location, and control of provider access to your systems
• Hybrid: agency analysts during office hours and a provider after hours, which works only with a well-defined handover
• Shared service for a cluster or ministry: economies of scale and consistent tooling, but needs governance for data sharing, priorities, and funding

The decision factors are data sensitivity, whether logs may leave the agency or the country, the skills you can hire and retain, the budget, and the coverage hours you need. A practical path for many agencies is hybrid first, moving functions in-house as skills grow.

People and shifts: planning arithmetic

One continuously staffed seat covers 168 hours a week. If a person gives about 36 to 40 productive hours a week after leave, holidays, and training, one 24x7 seat needs roughly 4.2 to 4.7 people (168 divided by 40, and by 36), so plan on about 5. A two-analyst 24x7 pattern therefore needs roughly 8.4 to 9.3 analysts, so plan on about 9 to 10, before leads, engineers, and a manager. This is a planning estimate, not a standard; adjust it to your HR rules.

• SOC manager: owns the service, reporting, and escalation
• Tier 1 analysts: triage alerts and follow playbooks
• Tier 2 analysts: investigate and run containment
• Detection engineer and threat hunter: build, test, and tune detections
• Platform engineer: runs the SIEM, collectors, and automation
• Liaisons: contacts in IT operations, legal, and privacy

Processes that make it work

• Severity model and service levels: agreed definitions of severity with response and escalation times
• Incident lifecycle: aligned with NIST SP 800-61 Rev. 3 and the NIST Cybersecurity Framework 2.0 functions
• Playbooks for the likeliest scenarios, such as phishing, ransomware, account compromise, website defacement, and data leakage
• Evidence handling: preserve logs and images so findings hold up for investigation or legal use
• Detection lifecycle: every detection has an owner, a test, and a review date
• Exercises: tabletop and technical drills, see Network and Cyber Security Simulators: Types and Uses

Measure and mature

Measure what the SOC achieves, not how many alerts it closes. Useful measures are time to detect and time to respond (see Using AI in the SOC to Reduce MTTD and MTTR), share of critical systems with log coverage, share of priority ATT&CK techniques with a tested detection, false-positive rate, and exercise results. Use them to place the SOC on a maturity scale and to justify the next investment.

Write the TOR to buy outcomes

In a TOR, specify outcomes and how you will verify them, not just product names. A checklist to adapt:

• Scope: number and types of log sources, sites, and cloud services
• Sizing basis: expected events per second or data volume per day, with growth
• Retention: by tier, with the legal and policy basis agreed with your legal team
• Data location and ownership: where data is stored, who owns detections and reports
• Service hours and levels: severity definitions, response and notification times, reporting formats
• Staff: roles, qualifications, and continuity of named personnel
• Platform security: segregation, MFA, logging and audit of provider access to your systems
• Integration: ticketing, existing EDR, firewalls, and directory
• Acceptance tests: attack simulations mapped to ATT&CK and a trial period on your own sample logs
• Exit and transition: data export, ownership of detection content, and knowledge transfer

Ask bidders to prove it rather than promise it: run the acceptance tests in a proof of concept before award, and compare their detection results against the same scenarios.

A phased roadmap

Build in phases rather than all at once. Each phase ends with something you can demonstrate.

• Phase 0, months 0 to 3: charter, scope, asset inventory, coordination contacts, and incident reporting contacts
• Phase 1, months 3 to 9: collect priority logs, stand up the SIEM and endpoint visibility, begin monitoring in office hours with a first set of detections
• Phase 2, months 9 to 18: extend to 24x7 or provider coverage, add playbooks and case management, automate repetitive steps
• Phase 3, from month 18: threat hunting, detection tuning against ATT&CK, regular exercises, and metrics reviewed by management

Common mistakes

• Buying a SIEM before choosing log sources and use cases: the platform fills with data nobody uses
• A SOC with no authority: analysts can see a threat but cannot isolate a system
• No playbooks: every incident is improvised
• Alert fatigue: untuned detections bury the real signals
• A SOC separate from IT operations: findings never turn into patches and fixes
• 24x7 on paper only: a contract or roster that does not cover nights and holidays in practice
• Ignoring retention and legal duties: logs deleted before an investigation needs them

Start today

• Name the owner and write a one-page charter
• List your critical systems and the log sources for each
• Confirm your legal position: whether you are designated CII, who your regulator is, and what your code of practice requires
• Pick the operating model and the first-phase scope
• Test your incident reporting path with a tabletop exercise, using Ransomware: Five First Steps as a scenario

To see where your agency stands before you plan, try the self-assessment.

Accuracy and scope

This report summarizes the Cybersecurity Act B.E. 2562 from an unofficial English translation. The Thai text prevails. Notifications from the National Cybersecurity Committee, the CRC, NCSA, and your regulator change over time, so check the current versions. Nothing here is legal advice.

Vulnerability scan findings have to become real fixes together with IT operations; see how to run that cycle in A Vulnerability Management Program That Works.

Cloud log sources are another input a SOC must bring in. See Cloud Logging and Detection: What to Log.

For a deeper comparison of the operating model choices above, see SOC Models: In-House, MSSP or Hybrid Compared.

Log sources and retention periods are the foundation of a SOC; see how to set the policy in Log Management: What to Log and How Long to Keep It.

State agencies and CII organizations also have legal duties; see Thailand Cybersecurity Act and CII: Who Is Covered.

References and further reading

• Cybersecurity Act B.E. 2562 (2019), unofficial English translation: Sections 44 to 46, 49, and 54 to 58
• ThaiCERT: CII agencies: sectors and obligations in summary
• NCSA (National Cyber Security Agency): official notifications and guidance
• Digital Government Standards (DGA): government digital standards and guidance
• MITRE: 11 Strategies of a World-Class Cybersecurity Operations Center: SOC strategy reference
• NIST SP 800-61 Rev. 3: Incident Response Recommendations
• NIST Cybersecurity Framework 2.0
• NIST SP 800-92: Guide to Computer Security Log Management
• CISA: Guidance for SIEM and SOAR implementation: including priority logs
• MITRE ATT&CK
• NIST SP 800-84: Test, Training, and Exercise Programs