Skip to content
PL EN
SECURITY ASSURANCE / IT AUDIT

IT security audit

We turn fragmented configuration and process into a clear map of risk, ownership and remediation order.

The objective is not checklist compliance. Standards provide a reference, while priority comes from impact on operations, data and the organisation’s ability to detect and handle an incident.

Discuss a security audit View public work
PEOPLE · PROCESS · TECH
Complete context
RISK BASED
Priorities
EVIDENCE
Validation
ROADMAP
Implementation plan
01 / DECISION CONTEXT

Who the audit is for

  • 01Organisations preparing for customer or regulatory requirements.
  • 02Teams without a current view of assets, access and controls.
  • 03Businesses following rapid growth, migration or a provider change.
  • 04Boards that need evidence-based security investment decisions.
02 / TEST SURFACE

Assessment areas

01

Architecture and access

We assess assets, networks, identities and trust boundaries.

  • Asset inventory and criticality
  • MFA, privileged access and joiner/mover/leaver lifecycle
  • Segmentation, remote access and suppliers
02

Resilience and operations

We test the ability to maintain and restore operations.

  • Backups, restoration and business continuity
  • Patching, vulnerability management and hardening
  • Logging, monitoring and incident response
03

Risk governance

Technical controls are connected to ownership and process.

  • Policies, owners and exceptions
  • Supplier and data risk
  • Mapping to agreed requirements
03 / DELIVERY

How the audit works

  1. BR / 01

    Business context

    We start with critical services, data, obligations and tolerance for downtime.

  2. BR / 02

    Interviews and evidence

    We speak with owners, review configuration and request proof that controls operate.

  3. BR / 03

    Technical validation

    Selected risks are checked with tools and safe tests instead of relying on declarations.

  4. BR / 04

    Risk map and roadmap

    Findings become initiatives, owners, dependencies and a realistic sequence.

04 / EVIDENCE STANDARD

Backups exist, but restoration capability is unproven

FINDING MODEL / NO CLIENT DATA

Having backup files is not the same as restoring a service within the required time.

This is a documentation example, not a finding from a specific organisation.

E-1

No defined RTO/RPO for a critical service

E-2

Restore testing excludes dependencies and keys

E-3

Results have no owner or acceptance criterion

E-4

Remediation starts with a controlled restoration exercise

05 / OUTPUT

Final package

01
Executive summary and risk profile
Included deliverable
02
Evidence-backed findings register
Included deliverable
03
Mapping to agreed frameworks or requirements
Included deliverable
04
30/60/90-day roadmap
Included deliverable
05
Prioritisation workshop and optional retest
Included deliverable
06 / QUESTIONS

Common questions

← All services
01Does the audit provide ISO 27001 certification?+

No. We can assess readiness and gaps, while certification is issued by an accredited certification body.

02Does it include a penetration test?+

Technical validation can be included, but a full penetration test is a separate, deeper engagement. Both scopes can be combined where justified.

03How many client staff need to participate?+

We need a project owner and short access to people responsible for IT, security and critical processes. The schedule is designed not to block operations.

BR / NEXT STEP

Need a clear picture of security risk?

We will agree critical systems, requirements and the level of detail needed by leadership and IT.

Discuss a security audit
NDA · clear scope · direct communication