Why Manual Security Hardening Creates Compliance Gaps in Financial Institutions

Financial institutions depend on thousands of technology components to support customer services, internal operations, payments, data processing and regulatory reporting. These components may include physical and virtual servers, operating systems, databases, cloud resources, middleware and network devices.

Every component must be configured securely. Unnecessary services should be disabled, access permissions should follow approved policies, logging should be enabled, insecure protocols should be restricted and system settings should follow the organisation’s security baseline.

The challenge is not simply defining these requirements. The real challenge is applying them consistently across a large and constantly changing technology environment—and proving that they remain in place.

When security hardening depends heavily on manual work, a control that appears correct on paper may not be implemented consistently in practice. One system may follow the approved baseline while another contains an outdated setting, an unauthorised exception or a change that was never properly recorded.

Over time, these differences create compliance drift: the growing gap between the organisation’s approved security standard and the actual configuration of its technology environment.

The Hidden Weakness of Manual Security Hardening

Security hardening is sometimes treated as a one-time activity completed when a system is first deployed. In reality, technology environments do not remain static.

Configurations change during troubleshooting, upgrades, application deployments, migrations, emergency fixes and day-to-day administration. New servers and cloud resources are introduced, while different teams may interpret the same security policy differently.

Without automation, financial institutions commonly face several challenges.

1. Inconsistent implementation of security baselines

Even when a security baseline is clearly documented, administrators may apply it differently across systems. A setting may be missed, entered incorrectly or adjusted to resolve an immediate operational issue without being restored later.

The result is an environment in which systems serving similar purposes no longer have the same security posture.

2. Configuration drift between reviews

Periodic reviews can identify some deviations, but they only provide a snapshot at a particular moment. A system that passed a review may drift away from the approved baseline after a later manual change.

If the institution lacks a repeatable way to check configurations at scale, non-compliant settings may remain undetected until the next audit, security assessment or incident.

3. Slow remediation across a large environment

When a security team introduces a new requirement—such as disabling an insecure protocol or updating an authentication setting—operations teams must identify the affected systems and apply the change.

Doing this manually across hundreds or thousands of systems takes time. It can also lead to partial implementation, especially when the environment spans data centres, disaster recovery sites and multiple clouds.

4. Weak or fragmented audit evidence

Auditors and risk teams may need evidence showing what was changed, who approved it, where it was applied, whether it succeeded and which exceptions remain.

Manual processes often leave this information scattered across spreadsheets, emails, screenshots, service tickets and administrator notes. Considerable effort is then required to reconstruct an accurate record.

5. Security teams become dependent on individual knowledge

If hardening procedures exist only as instructions understood by a small number of experienced administrators, the process becomes difficult to scale and repeat. Staff changes or time pressure can introduce additional risk.

Security controls should operate as an institutional capability—not depend on one person remembering every step.

Why This Matters to Financial Institutions

A single insecure setting does not always cause an immediate disruption. This can make compliance drift easy to underestimate.

However, a misconfiguration may weaken access control, reduce monitoring visibility, expose an unnecessary service or allow a system to operate outside the institution’s risk appetite. The larger and more complex the environment becomes, the harder it is to find these deviations manually.

This creates several business risks:

• Increased exposure to cyber threats caused by inconsistent or outdated controls

• Higher audit preparation costs and longer evidence-gathering cycles

• Difficulty demonstrating that security policies are operating effectively

• Greater reliance on manual checks and specialist staff

• Slower response when a baseline must be updated urgently

• Higher possibility of unauthorised or undocumented exceptions

• Inconsistent security across on-premises, cloud and disaster recovery environments

For financial institutions, security hardening is therefore not only a technical task. It is part of operational risk management, governance and regulatory readiness.

The Connection to Bank Negara Malaysia’s RMiT Policy

Bank Negara Malaysia’s revised Risk Management in Technology (RMiT) policy document, issued on 28 November 2025, places clear responsibility on financial institutions to maintain effective technology controls.

Under paragraph 10.17(a), a financial institution must maintain a current security baseline for hardening technology components and ensure that the baseline remains accurate and up to date.

Other RMiT expectations also reinforce the need for disciplined technology-risk management. For example, paragraph 9.2 requires the technology risk management framework to include risk controls, mitigations and continuous monitoring so that material risks can be detected and addressed in a timely manner. Paragraph 10.19 requires institutions to continually monitor the effectiveness and security of technology in use as the technology and threat landscape evolves.

These requirements do not prescribe Ansible or any single technology. However, a heavily manual operating model can make the requirements increasingly difficult to execute consistently as infrastructure grows.

Automation can support RMiT alignment by helping an institution:

• Translate approved security requirements into repeatable technical controls

• Apply those controls consistently across relevant systems

• Detect deviations from the intended configuration

• Remediate approved issues through controlled workflows

• Record execution results for review and audit purposes

• Reduce the time between identifying a control gap and correcting it

Automation alone does not guarantee regulatory compliance. Governance, risk assessment, approvals, testing, segregation of duties and human oversight remain essential. Its value is in making approved controls more consistent, traceable and scalable.

Moving from Written Standards to Security as Code

Many institutions already have hardening checklists and security standards. The problem is that a document cannot enforce itself.

With Red Hat Ansible Automation Platform, approved configuration requirements can be represented in human-readable automation playbooks. These playbooks define the intended state and execute the same approved steps across the selected systems.

For example, an institution can build automation to:

• Configure password and authentication policies

• Disable unnecessary services and insecure protocols

• Apply approved file and directory permissions

• Configure system logging and audit settings

• Enforce firewall or network-device configuration standards

• Validate whether required security settings are present

• Restore an approved configuration after unauthorised drift

• Produce execution records that support operational review

Because the automation content can be version-controlled, changes to the baseline can be reviewed, tested and approved before use. This creates a clearer connection between policy, implementation and evidence.

A Controlled Hardening Workflow

Security automation should not mean making uncontrolled changes across production systems. A mature approach uses automation within an approved governance process.

1. Define the approved baseline

Security, risk and infrastructure teams agree on the required configurations, applicable systems, exceptions and validation criteria.

2. Convert the baseline into reusable automation

The requirements are developed as tested Ansible playbooks or roles. The content becomes a standard method for applying and checking the controls.

3. Test before production deployment

The automation is validated in a controlled environment to identify application compatibility issues and unintended operational impacts.

4. Apply changes through approvals and access controls

Role-based access, job templates, credentials and approval workflows help ensure that only authorised users can execute approved automation against the correct systems.

5. Validate and record the outcome

The institution can review which systems were changed, which tasks succeeded or failed and which exceptions require further action.

6. Repeat the assessment

Hardening is treated as a continuous control. Regular checks identify whether systems have drifted from the intended state so that the institution can investigate and remediate appropriately.

What Changes with Enterprise Automation

The objective is not to remove human accountability. It is to allow security, operations, risk and audit teams to work from the same approved and repeatable process.

Southeast Asian Case Analysis: Asian Development Bank, Philippines

The Asian Development Bank (ADB) is a multilateral development bank headquartered in Metro Manila, Philippines. Its technology environment supports operations across a broad regional footprint.

According to Red Hat, ADB sought to improve operational efficiency and consistency while reducing human error. It selected Red Hat Ansible Automation Platform to provide standardised automation across its on-premises and public-cloud environments.

The publicly available case information does not state that this project was specifically a BNM RMiT compliance initiative, and ADB is not being presented as an institution governed by BNM. Its value as a Southeast Asian example is the operational principle it demonstrates: when infrastructure spans different platforms and environments, standardised automation can create a more consistent way to carry out technology operations.

For Malaysian financial institutions, the lesson is relevant. Security and compliance requirements become harder to enforce when every environment has its own manual procedures. A common automation approach can help teams translate approved standards into repeatable actions across hybrid infrastructure while reducing variation and human error.

Key lesson

A security standard becomes more effective when the organisation can apply, validate and evidence it consistently—not merely document it.

Where Financial Institutions Can Begin

Security hardening automation does not need to start with the entire environment. A focused first phase can demonstrate value while limiting operational risk.

A practical starting point may include:

1. Select one clearly defined security baseline and a manageable group of non-production systems.

2. Identify the manual steps, approvals, exceptions and evidence currently required.

3. Convert the repeatable requirements into tested automation content.

4. Compare the existing systems against the approved baseline.

5. Remediate selected gaps through a controlled workflow.

6. Measure consistency, execution time, failure rates and evidence quality.

7. Expand gradually to additional platforms and environments after governance and testing are established.

This approach helps the institution build confidence, strengthen internal capability and establish an automation model that can scale.

How Wiki Labs Supports Enterprise Automation

Wiki Labs helps organisations move from isolated scripts and manual procedures towards a governed enterprise automation capability.

As an experienced Red Hat partner serving Malaysian enterprises, including organisations in banking, financial services, insurance, telecommunications and the public sector, Wiki Labs supports automation initiatives through its CBOT methodology:

• Consult: Identify operational pain points, control requirements and suitable automation priorities.

• Build: Develop, test and integrate reusable automation workflows around the organisation’s environment.

• Operate: Support controlled deployment, governance, monitoring and continuous improvement.

• Transfer: Equip internal teams with the knowledge and capability to manage and extend automation confidently.

For security hardening, this can include baseline discovery, use-case prioritisation, proof-of-concept development, workflow design, integration planning and capability transfer.

Conclusion

Financial institutions cannot rely on written security standards alone. As technology environments expand across data centres and clouds, manual hardening creates inconsistency, slows remediation and makes compliance evidence difficult to maintain.

Enterprise automation provides a practical way to convert approved security requirements into controlled, repeatable and traceable actions. It can help institutions reduce configuration drift, improve operational consistency and strengthen their ability to support BNM RMiT expectations.

The important shift is from treating security hardening as a one-time checklist to managing it as a continuous, governed and measurable process.

Explore Enterprise Automation

Speak with Wiki Labs to explore how security hardening and compliance workflows can be automated safely across your infrastructure.