CYBER Mentors & Consultants

21/09/2026

INFORMATION SECURITY POLICY REVIEW

The policy said "annual review." It hadn't been touched in three years.

During a recent ISO 27001 internal audit of a client’s ISMS, the client responded to our DRL-document request list. We received a policy library that looked complete on paper.

ISMS policy, acceptable use, access control and lotS more. All policies signed off, version controlled but 95 last reviewed 3 years ago, which was the first audit finding

Nobody had a bad reason for not reviewing policies. It's just what happens when policy ownership sits with whoever wrote it originally, and that person changed roles two years ago. Lack of consistent policies review could be several other governance reasons

WHAT WE DID
I. We didn't rewrite everything from scratch.
II. We identified policy owners and assigned all policies the right owners
III. We built a simple owner-and-review-date register, and gave leadership a one-page view of what was overdue with owners assgined
IV. We also helped the client to automate annual document review process with calendar reminder configured
V. We further unified policy review dates to help resolve the problem of scattered review dates

If your policy library hasn't been touched since it was written, that's not a documentation problem, it’s a governance problem.

07/04/2026

Clarifying when Risk Assessment should take place during ISO 27001 Certification



There have been different interpretations of the requirements of Clauses 6 and 8 of the standard regarding when risk assessment should happen

While some implementers think that risk assessment is performed in both clauses, others think actual risk assessment is performed in clause 8 while clause 6 is only to document risk assessment methodology and risk treatment plan

We all know that SoA is produced in clause 6. The BIG question is that if risk assessment is performed ONLY in clause 8, how would you know which controls to include in SOA if there is no risk assessment happens in clause 6?

The answer is: you cannot produce a meaningful SoA without a conducting risk assessment first, and the standard knows this. The sequencing in the standard is logical, but confuses many implementers

Clarifying further:

Clause 6.1.2 says: define your methodology and perform an initial risk assessment.

Read carefully, Clause 6.1.2(c) requires the organisation to “DEFINE (document methodology) & APPLY (implement what you have defined) the risk assessment process” it is not purely methodology definition.

It requires actual identified risks with likelihood and impact scores to be produced.

Clause 6.1.3 then says: based on those identified risks, select controls, produce the SoA, and document the risk treatment plan.

Read 6.1.3a carefully “select appropriate information security risk treatment options, taking account of the risk assessment results”.

How then can you have risk assessment results without first conducting risk assessment?

Clause 8.2 then says: perform the risk assessment “at planned intervals and when significant changes occur”.

Meaning that you perform your subsequent risk assessments after the initial one, to keep the risk register current. The subsequent risk assessment is triggered by changes and it is routinely done

Clause 8.3 says: implement the risk treatment plan that was documented in 6.1.3 and keep implementing it as 8.2 updates the risk picture.

To summarise, the real sequence is:



Step 1 - 6.1.2 Define methodology AND perform the initial risk assessment

Step 2 - 6.1.3 Select controls, produce SoA, document RTP based on the result of risk assessment in 6.1.2

Step 3 - 8.2 Perform subsequent risk assessments as part of annual reviews, change-triggered

Step 4 - 8.3 Implement and maintain the RTP updated as 8.2 produces new outputs



Clause 6.1.2 is doing double duty: it is both the methodology definition and the first ex*****on. Clause 8.2 is the repeat cycle (routine) as part of maintaining and improving the ISMS

06/03/2026

Is Cyber Security actually a COST centre?

Transitioning from Accounting to Cyber Security, I see one main similarity between both- they are simply perceived as “COST CENTRES”

Just as football strikers always win “player of the month”, “Ballon d’or” at the expense of defenders and goal keepers, sales and revenue generating teams always win “employees of the month”

THE CHALLENGE:
Leadership sees cyber security as a cost centre.
Budgets increase…
Tools increase…
But the value is not always visible – we do not communicate our value addition

THE REALITY
Cyber security may not generate revenue, but it does something just as important:
--Protects revenue
--Prevents financial loss
--Defends business operations
--Protects customer trust

THE WAY OUT
Communicating this clearly to the board is key- but how do we communicate
1. Translate cyber issues into business risk
Boards are not interested in vulnerability counts or patching statistics.

Instead of saying:
“3,000 vulnerabilities were remediated this quarter.”

Explain the business impact:
“Critical vulnerabilities that could enable ransomware attacks were removed, reducing the risk of operational disruption and financial loss.”

Always connect cyber activity to business outcomes.

2. Show what your team prevented
Cyber security success is often invisible.

Leadership rarely sees the crises that never happen because of the work we do
--Phishing attacks blocked
--Malware stopped
--Suspicious logins prevented - unsuccessful login attempts
--Vulnerabilities fixed before exploitation
--Risks mitigated

3. Demonstrate cost avoidance
Show what this incident would have cost the organisation – use a case study of a recent breach suffered by other organisations

--Examples could include:
--Ransomware recovery costs
--Operational downtime
--Regulatory penalties
--Reputational damage

4. Report cyber posture, not just technical metrics
Boards need clarity, not complexity.

Focus your reporting on:
--Top cyber risks facing the organisation
--Risk trends over time
--Security improvements made
--Incident readiness and response capability

hashtag hashtag hashtag hashtag hashtag hashtag hashtag

09/11/2025

IT Risk Assessment Interview Confusion

Talk me through the process of RISK ASSESSMENT not same as Talk me through the process of RISK MANAGEMENT



Risk Management Process involves:

Ø Risk program/policy/strategy

Ø Conduct Risk Assessment

Ø Conduct Risk Treatment

Ø Monitoring (Risk Register, periodic review)

Ø Risk Reporting

With question about Risk Assessment Process, please ask the interviewer if he wants you to respond using NIST process or using ISO 27005/27001 risk assessment process.

Please what the video below for details, including other risk related interview questions

https://youtu.be/m8j-u1FWghU

,

Cybersecurity Interviews: Risk Management vs Risk Assessment – Common PitfallsAre you preparing for a cybersecurity or GRC interview and struggling to explai...

09/10/2025

How we helped a Fintech client cut audit prep time by 60%

One of the biggest challenges we see in regulated industries like fintech is audit fatigue — endless spreadsheets, scattered evidence, and last-minute document hunts.

We recently worked with a fintech client who faced exactly that. Every audit cycle meant weeks of manual effort just to pull together compliance evidence for ISO 27001, SOC 2, and FCA requirements.

Here’s what we did in the absence of a GRC Software

1. Centralised Their ISMS
We implemented a single ISMS dashboard that linked controls, risks, assets, incidents, and evidence — all in one place. No more siloed spreadsheets or version chaos.

2. Automated Evidence Collection
We integrated key systems so audit evidence (like logs, access reviews, and risk updates) flowed directly into the dashboard. This eliminated the scramble for screenshots and ad-hoc uploads.

3. Mapped Controls Across Frameworks
We built a unified control library that cross-referenced ISO 27001, SOC 2, and FCA compliance needs. One control update automatically reflected across all frameworks.

4. Created Audit-Ready Reporting
We designed real-time reports for auditors — clear, consistent, and traceable back to the control owner. Audit prep time dropped by 60%, and stress levels dropped even more.

The result?
• Faster audits.
• Stronger control visibility.
• Confidence across compliance teams

This approach didn’t just save time — it changed how the client viewed their ISMS: from a compliance burden to a strategic business enabler.

03/09/2025

Audit Question Spotlight

During an ISO 27001 audit, when asked

“How do you know your security controls are actually working?”

Here’s how we answered

1, Control objective

Every control has a purpose. We start by stating what the control is designed to achieve — the risk it addresses and the outcome it should deliver.

2, Control effectiveness is measured

We don’t assume controls work; we measure them. This means defining clear criteria, indicators, or benchmarks that show whether a control is performing as intended.

3, Monitoring & review activities

Controls are only effective if they’re monitored. We described how we perform ongoing checks, scheduled reviews, and automated monitoring to validate performance.

4, Demonstrate audit evidence

It’s not enough to say “we do it” — auditors want proof. We pointed to reports, logs, system outputs, and audit trails that provide tangible evidence of control operation.

5, Link to continual improvement

Finally, we explained how any weaknesses are addressed through corrective actions, risk register updates, and ISMS improvements — ensuring controls stay effective over time.

The auditor was satisfied because the response showed structure, evidence, and improvement — not just theory.

Summary: If you’re preparing for an audit, remember: objective → measure → evidence → improvement. That’s the language auditors trust.

13/08/2025

Which is your favourite quote? No right or wrong answers please

11/08/2025

IT Risk Management – What Auditors Really Want to See

If you’re preparing for an ISO 27001 audit, remember — auditors aren’t just looking for a long list of risks. They want to see a clear, structured risk management process, ownership assigned, assessments completed and risk snapshots
Here’s a quick checklist to what auditors would like to see:

1. Risk management framework & methodology
Approved process or methodology for identifying, assessing, treating, and accepting risks, risk scale, risk calculation, risk appetite, with a consistent scoring model linked to Annex A controls.

2. Asset-based risk identification
Up-to-date asset register, clear ownership assigned to each asset, and risks linked to assets and business processes.

3. Risk evaluation & prioritisation
Consistent criteria for defining high, medium, and low risks, considering legal and regulatory requirements. Same risk scale and risk score are used across the organisation

4. Risk treatment process
Documented treatment plans, specifying controls, responsible risk owner, deadlines for mitigation, selected treatment mapped to Annex A controls, and evidence that senior management has formally approved or signed-off any residual risk that remains after treatment.

5. Ongoing monitoring & review
Regular risk reviews, updates to risks when there is an incident or when new threats or vulnerabilities emerge. Evidence of risk tracking metrics and control effectiveness.

6. Isms integration
Risks linked to ISMS objectives, feeding into management reviews, with updates from incident lessons learned.

Audit show me tip!

When an auditor asks, “Show me your risk management process in action”, be ready to:
1. Walk them through your risk methodology document.
2. Open the risk register and demonstrate recent updates.
3. Show a Risk Treatment Plan with before-and-after scoring.
4. Highlight management sign-off on residual risk.

05/08/2025

Internal Audit Day Tips: Clause 9.2 Internal Audits

If you want external auditors to see that your ISMS is alive and well-managed,
Here’s a 5-step checklist to ensure your internal audits are solid and audit-ready:

1. Risk-based audit schedule:
Prioritise audits based on systems that process sensitive data or have high exposure to threats. This shows maturity and planning.

2. Internal auditor competence:
Maintain training records and experience logs. If using external auditors /consultants, keep their bios and contract details as evidence.

3. Clear Audit Reports:
Include objectives, findings, non-conformities, and supporting evidence. Reports should be professional, consistent, and actionable.

4. Tracked Follow-Ups:
Every finding should have a logged corrective action with deadlines, status updates, and owners assigned. Keep record of corrective actions in Excel or any project management tool for effective tracking

5. Reviewed by Management:
Ensure audit results are presented in management review meetings and fed into continual improvement. There should be a sync between audit findings and risk register.

Auditors will see your ISMS is alive and well-managed.

03/08/2025

ISO 27001:2022 New Controls Implementation SIMPLIFIED

A.5.23 – Information Security for Use of Cloud Services



This new ISO 27001:2022 control helps organisations secure the full cloud lifecycle — from selection to exit. Let’s break it down

WHAT IT’S ABOUT

This control requires organisations to define and manage cloud-related security requirements — whether you're buying, using, managing, or terminating cloud services.

Shared responsibility model:

You must understand who (you vs. the provider) is responsible for what — especially for controls like access, backup, data location, and incident response.

TECHNOLOGY

Ø Most cloud platforms already offer built-in security tools.

Ø Your job is to make sure those tools are actually used and aligned with your risk profile.

Ø In some cases, you may need to upgrade your service level or switch providers entirely.

PROCESSES YOU’LL NEED

Establish a cloud security governance framework that includes:

Ø A cloud security policy

Ø Risk assessments before using any cloud service

Ø Provider selection criteria (security certifications, SLAs, etc.)

Ø Roles & responsibilities — both internal and external

Ø Exit strategy (e.g., data return, backup, jurisdictional controls)

Ø Define how incidents in the cloud are handled and how you monitor service security continuously.

PEOPLE

Cloud risks are often user-driven. So:

Train staff on safe cloud usage

Make sure business units know which tools are sanctioned

Provide clear reporting lines for cloud-related incidents

DOCUMENTATION IDEAS

While not required by ISO 27001, these docs will boost your implementation:

Ø Cloud Security Policy

Ø Supplier Security Policy

Ø Design a Cloud Exit Checklist

Ø Incident Response Plan (with cloud-specific playbooks)