SIEM RFP questions

A credible partner sizes from measured or estimated daily ingest per source, then multiplies by retention and a safety factor. For Graylog, the documented guidance is to size log storage as daily ingest times retention days times 120 percent, and to give the message journal 3 to 5 times daily ingest on SSDs. Ask the partner to show that arithmetic for your numbers, state which sources are assumed to be chatty (firewalls, Windows domain controllers, cloud audit trails), and explain how they measured ingest during a pilot. Also ask how hot and archive tiers are split, since that choice changes both storage and search speed. Expect the quote to rise with ingest volume, retention length, replica count and the number of cluster nodes, and ask for each of those assumptions in writing.

The partner should give you a written source inventory with a method for each source: a Wazuh agent, syslog from network devices, an API pull for cloud or SaaS audit logs, or Beats and GELF inputs in Graylog. For each source, ask who writes and tests the decoder or parser, how a field mapping is versioned, and what happens when a vendor changes its log format. Agentless devices that cannot run an agent depend on syslog and periodic API probing, which the Wazuh components documentation describes, so ask which devices will rely on that path. Confirm that onboarding is counted as a fixed deliverable with an acceptance test, such as a documented event count per source and a sample search for each.

Clarify ownership before the contract is signed: the partner may write the initial rule set, but your team or a retainer must own tuning, false-positive review and new use cases. Ask which rules ship on day one, how each maps to a threat or control, and how alert thresholds are tested against your historical logs. Ask whether Wazuh rules, Graylog event definitions or prebuilt content will be adapted, and who documents the change history so an auditor can see when a rule changed and why. Good answers name a rule lifecycle (draft, test, approve, deploy, review) and a named owner on each side. Ask how alert routing to PagerDuty, Slack or email is set up and who receives after-hours pages.

A good answer shows where logs are stored, how long each tier is kept, and how deletion and modification are controlled. Ask the partner to show index lifecycle or rotation settings, such as Graylog retention that deletes the oldest indices, and to demonstrate that retention matches the framework you are assessed against. Ask how logs are protected from change: separate write and admin roles, forwarding to a restricted archive, hashing or signed exports, and audit logs of administrator actions. Request sample evidence, such as a retention configuration export, an access review record and a restore test. Confirm the partner prepares this evidence only; the audit opinion comes from your independent assessor.

The partner should describe a dated upgrade plan tied to vendor release cadence and support windows. For OpenSearch, the project states that a version stays in maintenance until the next major version enters maintenance or one year passes, whichever is longer, and that maintenance releases carry bug fixes and security patches but no new features. Ask which OpenSearch line you will run and when it leaves maintenance. For Wazuh, ask how the 4.14 patch releases are tested in a staging cluster, how agents are upgraded, and how rollback works. Ask whether Graylog compatibility is checked against the matrix before any upgrade, since Graylog 7.0 to 7.2 pair with specific MongoDB and OpenSearch ranges.

Logs often contain personal data and credentials, so the SIEM needs its own access model. Ask how the partner configures role-based access, and whether document-level and field-level security, field masking and audit logs are used. The OpenSearch Security plugin documents these features along with SAML, OpenID Connect, LDAP and Active Directory authentication, so ask which backend will connect to your identity provider and how service accounts are limited. Ask how TLS is applied to node and client traffic, how user impersonation is restricted, and how a quarterly access review is evidenced. Request the role map as a deliverable so you can check which team sees which sources.

Support after go-live is usually a separate recurring agreement from the build. Ask the partner to list what the retainer covers: patching, upgrades, rule tuning, source onboarding, backup and restore tests, capacity reviews and incident support, with response expectations written as stated commitments you can verify. Ask who is on call, what hours are covered and how escalation to the vendor works. Cost drivers include the number of sources, the amount of rule change each month and the frequency of upgrades. Ask for the build and recurring components as separate lines in the written scope so you can see one-time versus ongoing spend. If you use Graylog Enterprise or Graylog Security, ask which paid features and 24/7 support are included, since the published prices are per year with a minimum volume.

Yes, if the partner transfers knowledge in a structured way, and the answer should describe that transfer in writing. Ask for runbooks covering installation, the Wazuh cluster or Graylog and OpenSearch nodes, index rotation, backup and restore, and alert triage. Ask how knowledge transfer is scheduled, which staff are trained, and whether they shadow the first real incidents and upgrade cycle. Confirm which documentation, configuration and rule sources you will own, and where they are stored. Good partners treat handover as a deliverable with acceptance criteria, not an informal ending to the project.