How Should Philippine Security Teams Evaluate a SIEM?
Should a Philippine security team buy a SIEM now?
If your analysts cannot reconstruct a suspicious admin session from identity, endpoint, cloud, and network records in one working session, your next security purchase should probably address detection evidence before it adds another control. A SIEM can do that. The buying test is whether it improves decisions during an incident.
The threat data supports testing that question now. Verizon's 2026 Data Breach Investigations Report says exploitation of vulnerabilities accounted for 31% of initial access in breaches, while ransomware appeared in 48% of all breaches. IBM's 2025 Cost of a Data Breach Report puts the global average breach cost at US$4.4 million, down 9% from the prior year, and attributes the decline to faster identification and containment. That does not prove a SIEM will lower your cost. It does establish why detection and containment time belong in the investment case.
Takeaways
- Buy for a defined investigation or response outcome, not for log volume.
- Require a live test with your data before accepting a detection claim.
- Price the people, tuning, storage, and response work alongside the license.
- Assign an owner for each high-priority alert before production.
A SIEM is a reasonable next purchase when investigators spend too long gathering evidence, critical systems have no shared detection view, or existing alerts lack an accountable response path. If those conditions are absent, fix the operating process first. A new console will not create ownership.
Set the decision date before requesting proposals. If the team cannot name the incident questions and actions the system must improve, postpone procurement and write those requirements first.
What evidence should vendors produce before you shortlist them?
A slide showing hundreds of integrations proves very little. Your shortlist should depend on evidence from the systems that carry your highest-risk identities, transactions, and data. Use the same scenarios, timestamps, and acceptance rules for every bidder.
The table below is an original procurement test. Score each row only after the bidder demonstrates it with your sample data or a controlled proof of concept.
| Decision test | Evidence to require | Reject when |
|---|---|---|
| Source coverage | A named connector, required fields, time normalization, and failure behavior for each priority source | The answer is only a logo or product name |
| Detection quality | A replayed scenario with the alert logic, evidence, and known false-positive conditions visible | The rule cannot be explained or tuned |
| Investigation speed | One timeline linking account, device, system, action, and outcome | Analysts must open several tools to establish basic facts |
| Response workflow | A ticket or case with owner, severity, evidence, and escalation time | Alerts end in a shared inbox with no accountable person |
| Operational fit | Storage forecast, tuning plan, health checks, access model, and support boundary | License price excludes the work needed to keep detections usable |
Do not average the five rows into one convenient score. Source failure can invalidate a detection. A detection with no response owner is noise. A fast search with incomplete identity context can still send an analyst in the wrong direction.
Ask the bidder to state every dependency in writing: network path, service account, API entitlement, data transformation, retention tier, and staff role. Then attach those dependencies to the commercial proposal. Infocentric's SIEM service page describes the category; the procurement decision should still rest on demonstrated coverage and an operating model you can fund.
Which data should enter the SIEM first?
Start with the evidence needed to answer your first three incident questions. Which identity acted? What asset or application was touched? What changed or left the environment? That usually puts authentication, privileged activity, endpoint events, critical cloud control planes, network security records, and selected business applications ahead of low-value bulk feeds initially.
NIST Special Publication 800-92 states: “Log management is essential to ensuring that computer security records are stored in sufficient detail for an appropriate period of time.” The same publication treats log management as a process that includes generation, transmission, storage, analysis, and disposal. Collection is therefore only one control point.
Build the first ingestion plan in three tiers:
- Identity and privilege. Include successful and failed authentication, role changes, privileged sessions, and administrative changes. If privileged access is a material exposure, connect the plan to your PAM controls.
- Assets and control planes. Add endpoint, cloud administration, firewall, and other records needed to place the identity action on a device and route.
- Business evidence. Add the critical application records required to prove what happened to a payment, customer record, production job, or other material process.
For each source, document the owner, required fields, expected arrival delay, retention rule, and response when collection stops. Test clock drift and duplicate events. Confirm that analysts can distinguish a missing record from a clean result.
This ordering also keeps the program consistent with an identity-first Zero Trust journey: access decisions and activity need enough context to be checked, investigated, and challenged.
How do you test operations before signing?
Run the proof of concept as an incident exercise, not a product tour. Give each bidder the same small set of scenarios: a privileged role change outside an approved window, repeated authentication failures followed by success, a disabled log source, and a suspicious connection from a protected server. Record the time to detect, time to establish basic facts, analyst actions, and unresolved gaps.
For BSP-supervised financial institutions, the local anchor is explicit. BSP Circular No. 982, issued in 2017, places continuous monitoring of systems and networks and adequate incident response within information security administration. A SIEM proposal for a bank should show how the operating design supports those duties. The tool name is not the evidence.
Before approval, settle six operating questions:
- Who reviews each severity level, and during which hours?
- Who tunes noisy logic and approves a rule change?
- Who notices when an important source stops reporting?
- Which team may isolate a device, disable an account, or block a route?
- What survives a network interruption, site outage, or failed collector?
- Which records must be exported for audit, legal, or regulatory work?
Include one real interruption or recovery event in the test if it is part of your operating risk. A system that works only during a prepared demonstration has not passed.
If internal coverage cannot support those duties, compare the full staffing plan with a documented managed-service model. Keep the same acceptance measures. The final contract should name the data sources, use cases, response boundary, service hours, evidence retention, and exit method.
What should you ask in the final meeting?
Does every Philippine company need a SIEM?
No. A SIEM is justified when several systems must be correlated, investigations are slowed by scattered evidence, or monitoring duties exceed what existing tools and staff can manage. Smaller environments may first need sound logging, endpoint controls, identity administration, and a clear incident process.
Can a SIEM replace endpoint or identity controls?
No. It can collect and relate evidence from those controls, then support investigation and response. It does not remove the need to prevent unsafe access, manage privilege, patch exposed systems, or isolate compromised assets. Treat detection as one layer in the control design.
How long should logs be retained?
Set retention by investigation need, applicable regulation, contracts, litigation requirements, storage cost, and the sensitivity of the records. Do not copy a vendor default into policy. Document why each source has its period, who may access it, and how disposal is verified.
Should the service be managed or run internally?
Choose the model that can cover monitoring hours, engineering, tuning, investigations, and response authority without hiding handoffs. A managed provider can operate parts of the process, but the organization still owns risk decisions, business context, escalation contacts, and approved response actions.
What definition should anchor the program?
Use the full lifecycle rather than a dashboard count. NIST SP 800-92 defines log management as the process for generating, transmitting, storing, analyzing, and disposing of computer security log data. That scope gives policy owners five distinct control points to assign, test, monitor, and audit.