Author: lapperra

  • Policy

    Policy

    A policy is not yet an operational control.

    Organisations invest considerable effort developing cybersecurity policies, standards and control frameworks.

    That is important. But approving a policy does not mean the risk is actually being controlled.

    A policy might state that security events must be monitored, suspicious activity investigated and incidents escalated.

    The operational questions are different:

    • Who monitors the environment?

    • What exactly is being monitored?

    • Which events require investigation?

    • What determines when an alert becomes an incident?

    • Who must be notified and when?

    • What happens outside normal working hours?

    • How are actions and decisions recorded?

    • How does management know the controls are actually working?

    This is where governance must connect with operations.

    A useful way to think about the control chain is:

    Policy → Process → Procedure → Execution → Evidence → Assurance

    A Security Operations Centre, for example, can provide sophisticated monitoring, detection and response capabilities.

    But technology and monitoring alone do not complete the chain.

    The SOC must operate within clearly defined processes, responsibilities, escalation requirements and governance—and produce evidence that allows the organisation to determine whether its security controls are effective.

    That distinction matters.

    A policy states the intention.

    Evidence shows whether it works.

    #CyberSecurity#SOC#SecurityOperations#GRC#InformationSecurity#Governance#Lapperra

  • Security tools

    Security tools

    More security tools do not automatically create better security.

    Modern Security Operations Centres can have access to an impressive technology stack.

    SIEM. EDR. NDR. Threat intelligence. Vulnerability management. SOAR. Cloud-security tools. Identity monitoring.

    Each can provide valuable capabilities.

    But adding another security tool also creates more alerts, more telemetry, more integrations and potentially more complexity for the people expected to make sense of it.

    That raises an important question:

    How should an organisation determine whether its SOC is actually effective?

    The answer shouldn’t simply be the number of tools deployed, alerts generated or events processed.

    Management should be asking questions such as:

    • Do we have visibility across the systems that matter?

    • Are meaningful threats being detected?

    • How quickly are alerts investigated and prioritised?

    • Are genuine incidents escalated to the right people?

    • Can threats be contained before significant damage occurs?

    • Are recurring weaknesses identified and addressed?

    • Does management receive useful evidence about security performance and risk?

    Automation and AI can increasingly help correlate information, prioritise alerts and reduce repetitive analyst work.

    But they do not eliminate the need for well-defined processes, competent people, clear escalation criteria and human judgement.

    An effective SOC isn’t defined by how much technology it has.

    It is defined by how effectively it can detect, understand, respond to and provide assurance about security threats.

    #CyberSecurity#SOC#SecurityOperations#GRC#CyberResilience#InformationSecurity#Lapperra

  • AI Outsourcing

    AI Outsourcing

    You can outsource the AI service. You cannot outsource accountability.

    As organisations accelerate their adoption of Artificial Intelligence, many are turning to external providers for AI platforms, applications, agents and managed services.

    This can make AI capabilities easier and faster to deploy.

    But it also introduces an important governance question:

    Who remains accountable when something goes wrong?

    Singapore’s Monetary Authority has recently issued AI Risk Management Guidelines addressing governance, oversight, AI inventories, lifecycle controls and third-party AI dependencies within financial institutions.

    Although the guidelines are directed at the financial sector, the underlying governance principles are relevant to organisations adopting AI across virtually any industry.

    Using a third-party AI service does not eliminate the organisation’s responsibility to understand and manage the associated risks.

    Management should therefore be asking:

    • Do we know which AI services and capabilities are being used across the organisation?

    • What information can these services access, process or retain?

    • How do we assess the risks associated with external AI providers?

    • Who monitors the performance, reliability and security of these services?

    • What happens when the provider changes its models, functionality or operating conditions?

    • Are human oversight, escalation and accountability clearly established?

    • Can we transition to another provider or discontinue the service without unacceptable disruption?

    These questions become even more important as organisations move from AI applications that merely provide information towards AI agents capable of executing actions and making operational decisions.

    Third-party AI can deliver considerable business value.

    But supplier agreements, technical capabilities and service-level commitments are not substitutes for internal governance.

    You can delegate the service. You can delegate operational activities.

    But accountability for the risks remains with the organisation.

    #ArtificialIntelligence#AIGovernance#ThirdPartyRisk#RiskManagement#GRC#DigitalTransformation#Lapperra

    Source: Monetary Authority of Singapore — AI Risk Management Guidelines, 7 October 2026