Configuration and parameter changes

Wazuh Security Configuration Assessment can show that monitored endpoints match or fail the checks in its policies, which makes it useful as detective evidence over configuration state. It scans endpoints for misconfigurations using YAML policies, shipped mostly based on CIS benchmarks and extendable with custom policies, and checks files, directories, registry keys and running processes. Its policies are written around security baselines, so a check on a financial application parameter only works if you write a custom policy that reads that specific value. Confirm with your team whether the parameter lives in a file, registry key or database, because that decides whether the check can reach it at all. Keep scan results and policy versions so an auditor can see what was tested and when. The project is licensed under GPL-2.0-only, which affects how you distribute modifications, so have counsel review it if you ship custom code.

Fleet policies answer yes or no questions about devices, written as osquery queries, and the policies page shows which devices in each fleet are passing or failing each policy. That gives you a repeatable point-in-time view of endpoint configuration, which can support a control over settings on workstations or servers that feed financial processes. Fleet policies are oriented toward endpoints, so they are a weaker fit for parameters inside a server-side financial application or database. Confirm that osquery can read the specific file, registry value or setting you need, and whether the query runs often enough to catch a change between your review dates. Ask your team how failing results are recorded and who reviews them. Fleet is licensed under MIT, which is permissive, but your own policy content and evidence process still need to be designed and owned by your organization.

GLPI's Assistance module lets users create, follow and process tickets, problems and changes following ITIL practices, and it includes plannings, statistics, recurrent tickets and a Kanban view. Those features can hold the request, the business and IT approval, and the implementation record for a parameter change, which is the evidence trail auditors sample. Whether GLPI enforces that a change cannot close without an approval, and whether approval fields are required, depends on how you configure workflows and roles, so confirm this in a test instance. Ask how the change record links to the environment where the parameter changed, because a ticket alone does not prove what changed in production. GLPI is licensed under GPL-3.0-or-later. Set up the configuration, approval roles and retention rules as part of your documented process, and have the external auditor review a sample before relying on it.

Zammad is a web-based helpdesk that brings customer communication from email, chat, telephone and social media into one ticket system. It is mainly built for handling incoming requests, so it can capture the originating request from a business user for a parameter change, including the email thread and the requester's identity. It does not on its own track configuration state or prove what changed in an application, so it is best treated as the request and communication record that sits alongside a change tool and a configuration check. Confirm whether your team can configure approval steps and required fields for change-type tickets, or whether that work needs a separate system. Zammad is licensed under AGPL-3.0-only, which has network-use obligations if you modify and host it for others, so review that with counsel before customizing it.

No single tool produces complete parameter change evidence, and no tool makes a control effective by being installed. An auditor will ask for the approved request, the testing and approval record, and proof that the production value matches what was approved. Wazuh and Fleet can speak to current configuration state, GLPI or Zammad can hold the request and approval trail, and the link between them is a control your organization designs and operates. The external auditor decides whether the evidence is sufficient, and only that auditor issues an opinion on ICFR. DeployOpen can plan, implement, customize, integrate and document these tools inside your environment and prepare the evidence, but the organization owns the control and the evaluation is the auditor's. Ask for a written scope that names which parameters, applications and reports are covered before work starts.

The software licenses for these tools are free under their open-source terms, so the cost is in labor and infrastructure. One-time costs include designing the parameter inventory, writing custom checks or queries, configuring ticket workflows and testing that evidence can be produced. Recurring costs include running scans, reviewing failed results, maintaining policies after application upgrades, hosting the servers and keeping retention and access controls working. Costs rise with the number of financial applications, the number of parameters that drive calculations, the complexity of custom checks and how often the process runs. No supplied fact gives a price for this work, so ask any implementation partner for a fixed-scope quote that lists the applications, parameters and tools in scope, the deliverables and who maintains the controls afterward. Ask internal audit how many samples they expect to test.

The timeline depends on how many financial parameters you must cover, how many applications they sit in, and how complete your current change process is. Setup typically includes mapping parameters to the systems that hold them, writing and testing custom checks, configuring ticket workflows, running a dry run and reviewing sample evidence with your auditor. No supplied fact gives a duration, so treat any timeline as something to confirm in writing. Ask your team or partner which applications are first, whether a pilot on one parameter set is possible, and what must be ready before the auditor's walkthrough. Plan for the evidence to be tested over a full period, not just on the day you finish setup, because auditors usually test operating effectiveness over time.

Effort depends mainly on how many financial systems hold parameters, how many of those parameters drive automated calculations, matching or approval workflows, and how often they change. Each parameter store needs an inventory, a documented change path, a sample of changes traced to approvals, and periodic review of what is in production. Effort rises quickly when parameters are edited directly in production databases or through spreadsheets that feed a system, because those changes are harder to see and to trace. Effort falls when parameters live in a small number of controlled stores with logging and a single approval path. Ask any partner to estimate effort from your actual inventory, not from a generic package.

Timing depends on scope and the number of parameter stores. A company with one ERP instance and a handful of well-documented configuration tables faces a much shorter path than one with many applications, interfaces and reference tables maintained by different teams. No fixed duration applies to every organization. Ask for a timeline in the written scope that lists the parameter stores in each phase, the evidence to be produced and the dependencies on your team, so you can compare proposals on the same basis.

Your team owns the controls, so it must supply several things that no outside party can supply for you. These include the list of financially significant applications and the tables or files that drive their calculations, the business owners who approve parameter values, and access to change logs and ticket history. Engineers must confirm how parameters are actually changed in each system, including any direct database edits. Plan for named owners to review and sign off on the parameter inventory and to attend walkthroughs, since auditors will ask them to explain each change path.

Yes, many organizations run it in-house, provided the team understands both the financial logic of each parameter and the technical path that changes it. The work is largely recurring: maintaining the inventory, reviewing changes against approvals, reviewing production values, and keeping evidence organized for the external auditor. Teams often find the hardest part is not the tooling but the discipline of closing direct production edits. If your team lacks SOX experience or capacity, an outside partner can prepare systems and evidence, while management keeps ownership of the controls and their conclusions.

A written scope should name each parameter store and the financial process it supports, the change paths to be documented, the evidence to be prepared for each control, and the testing approach the partner will follow before handover. Ask which items are one-time work and which recur, such as periodic review and change sampling. Confirm who performs each task, what the client must provide, what is excluded, and how changes to the scope are approved. Ask how the partner will handle parameters held in systems the partner does not administer, and how the deliverables will be handed over.

An external auditor tests the controls under PCAOB AS 2201 and assesses IT risks under AS 2110. It will examine whether parameter changes are authorized and traceable, select samples of changes, and check that automated controls relying on those parameters are supported by effective IT general controls. The auditor will not design, implement or operate your parameter controls, and it will not prepare the evidence on your behalf in a way that makes it independent of management. Management must maintain its own assessment. Only the independent auditor issues the attestation report, and a partner's preparation work does not replace that opinion.

Start with the parameters that feed automated calculations, matching and approval workflows, then confirm that each change to them is requested, approved and recorded in a way that can be traced to a production change. Auditors commonly select changes and compare them to tickets and approvals, so make sure the change ticket, the approver and the production timestamp can all be matched. Confirm that the parameter values in production agree with what was approved, using periodic reviews or reconciliations. Your auditor should confirm the exact sample sizes and frequencies it expects for your environment.