The enterprise deal that exposed a security governance gap.

Executive summary

The company did not start its ISO 27001 project because someone in IT wanted another certification.

It started because an enterprise customer asked a question the company could no longer answer with policies, screenshots and assurances:

“Can you provide evidence of current ISO/IEC 27001 certification?”

The organisation was a 68-person Australian B2B SaaS provider handling commercially sensitive customer information. Its technology environment was modern: Microsoft 365, Microsoft Entra ID, Intune, Azure, GitHub, Atlassian and several specialist SaaS suppliers.

Its security was not poor.

Its problem was that security had developed organically.

MFA existed, but privileged access was not consistently governed. Backups ran, but restoration testing was poorly evidenced. Logging existed, but responsibilities for reviewing alerts were unclear. Staff access was removed when people left, but the process depended on several manually maintained lists. Suppliers were reviewed before purchase, but there was no consistent risk-based reassessment process.

And although the organisation had numerous security policies, it did not have an information security management system connecting business requirements, risks, controls, responsibilities, evidence, monitoring and improvement.

A major enterprise opportunity made that distinction suddenly important.

Aegentra was engaged to design and implement the organisation's ISO/IEC 27001:2022 ISMS, remediate priority technical and governance gaps, organise evidence and prepare the organisation for independent certification.

Engagement snapshot

The problem was not a lack of security tools

During the first workshop the management team described the company as already “reasonably secure.”

That assessment was fair.

The company had:

• MFA enabled for its core Microsoft environment;
• endpoint protection;
• cloud backups;
• a password manager;
• antivirus and endpoint detection;
• employment confidentiality clauses;
• basic security policies;
• source-code controls;
• audit logging; and
• an informal incident-response process.

If ISO 27001 were simply a list of security products, the company would have been close.

It is not.

Aegentra's initial assessment instead asked:

What information are we protecting?

What could realistically happen to it?

Who owns those risks?

Which controls have been selected because of those risks?

Who operates each control?

How frequently?

What evidence demonstrates that it happened?

How does management know the control is effective?

Those questions exposed a different picture.

Finding 1: Nobody could clearly define the ISMS boundary

The first issue was scope.

Engineering assumed the certification would cover Azure.

Management assumed it covered the whole company.

Sales assumed certification would automatically cover every product.

IT assumed Microsoft 365 sat outside the product environment.

None of those assumptions was sufficiently precise.

Aegentra mapped:

• the SaaS application;
• Azure production infrastructure;
• software-development processes;
• GitHub repositories;
• customer support;
• Microsoft 365;
• employee endpoints;
• HR processes;
• security administration;
• critical suppliers;
• information flows; and
• locations and remote-working arrangements.

The resulting ISMS scope was based on the actual service customers were buying and the people, systems and processes required to deliver it.

This prevented a common mistake: creating a scope so narrow that the eventual certificate provided little assurance to an enterprise customer.

Finding 2: The company had a security register, but not a repeatable risk process

The company's existing “risk register” contained items such as:

Cyber attack — High

Data breach — High

System outage — Medium

These descriptions did not provide enough information to drive security decisions.

Aegentra replaced this with a defined information-security risk methodology.

Each risk recorded:

• the asset or process affected;
• threat scenario;
• vulnerability or exposure;
• potential impact on confidentiality, integrity and availability;
• likelihood;
• inherent risk;
• existing controls;
• risk owner;
• proposed treatment;
• treatment owner;
• residual risk; and
• formal acceptance where appropriate.

Examples of risks identified

Account takeover

A phishing-resistant authentication gap affecting privileged and high-value accounts could allow an attacker to obtain access to corporate systems.

Excessive privileged access

Several administrators retained broad roles because access had accumulated as the company grew.

Source-code exposure

Repository privileges and third-party development integrations created a potential route to intellectual property and secrets.

Incomplete offboarding

A departing employee could be removed from Microsoft 365 while retaining access to independently managed SaaS applications.

Supplier compromise

Several critical suppliers processed customer or company information but had not been reassessed since procurement.

Recovery failure

Backups were operating, but evidence that critical workloads could actually be restored within business requirements was incomplete.

Insufficient monitoring ownership

Security logs existed, but escalation criteria, responsibilities and evidence of review were inconsistent.

This changed the ISO project immediately.

Instead of asking:

“Which of the 93 controls haven't we implemented?”

the team could ask:

“What treatment is appropriate for this risk?”

Finding 3: MFA was enabled — but identity was still one of the largest risks

MFA is an important security control, but “MFA enabled” did not mean identity risk had been solved.

Aegentra reviewed the Microsoft identity environment and found that different account categories were being treated almost identically.

The remediation programme introduced a clearer privileged-access model.

Changes included

• separate privileged and standard user accounts;
• Conditional Access baselines;
• stronger MFA requirements;
• legacy-authentication restrictions;
• reduced standing administrative privileges;
• documented emergency-access accounts;
• alerting and review around privileged activity;
• periodic access reviews;
• defined joiner, mover and leaver responsibilities; and
• stronger device-compliance requirements for access to sensitive information.

The project therefore turned “we have MFA” into a governed identity lifecycle.

That distinction matters in the Australian threat environment, where compromised accounts and business email compromise remain significant business threats. The Australian Signals Directorate’s 2024–25 threat report lists compromised accounts or credentials among leading incident types and business email compromise among the leading self-reported cybercrime threats for businesses. ASD Annual Cyber Threat Report 2024–25.

Finding 4: Offboarding worked — until Aegentra tested it end to end

HR advised that departing staff were removed immediately.

Microsoft 365 records supported that statement.

Aegentra then selected a previous departure and traced the person's access across the complete application inventory.

The Microsoft account had been disabled correctly.

Two independently managed SaaS applications had not been included in the original termination workflow.

The issue was not a careless administrator.

The issue was architecture.

There was no authoritative application register connecting:

employee → role → application → access owner → provisioning method → offboarding requirement

Aegentra introduced an application and information-asset register and redesigned the leaver process so that HR initiated one controlled workflow and system owners confirmed removal.

This became evidence for several parts of the ISMS rather than an isolated IT procedure.

Finding 5: Backups existed, but evidence of recovery did not

The organisation could show that backups completed successfully.

A certification auditor can reasonably ask a different question:

“How do you know you can recover?”

Aegentra worked with the technical team to define recovery expectations for critical systems and then perform a controlled restoration exercise.

The organisation recorded:

• system tested;
• recovery objective;
• backup used;
• restoration steps;
• elapsed recovery time;
• validation performed;
• issues discovered;
• corrective actions; and
• responsible owner.

The exercise identified a dependency that was not documented in the existing recovery procedure.

That finding was corrected before the certification audit.

The backup control was now not merely configured.

It had been tested.

The Statement of Applicability became the centre of the project

Aegentra did not recommend implementing all 93 Annex A controls simply because they existed.

After the risk assessment and treatment process, this illustrative implementation resulted in:

84 controls determined applicable

9 controls determined not applicable

Every decision was documented in the Statement of Applicability.

For applicable controls, the SoA recorded:

• why the control was necessary;
• implementation status;
• relevant risk or obligation;
• control owner; and
• supporting documentation or evidence.

For controls considered not applicable, the organisation recorded its justification.

This transformed the Statement of Applicability from an ISO template into a map between:

business context → risk → treatment → control → evidence

Technical security was only half the implementation

Aegentra divided remediation into interconnected workstreams.

Identity and access

• Conditional Access
• MFA
• privileged access
• administrator separation
• access reviews
• joiner/mover/leaver workflow
• emergency access

Endpoints

• device enrolment
• encryption
• endpoint protection
• compliance policies
• security baselines
• patch management

Microsoft 365 information protection

• information classification
• sensitivity labelling
• appropriate DLP controls
• audit configuration
• retention requirements
• privileged activity monitoring

Cloud and development

• Azure role-based access
• logging
• secrets management
• repository access
• protected branches
• peer review requirements
• development/change records

Supplier security

• supplier inventory
• information-security requirements
• risk classification
• due diligence
• contract requirements
• reassessment frequency
• exit considerations

People

• security responsibilities
• onboarding
• awareness
• confidentiality
• acceptable use
• role changes
• termination responsibilities

Resilience

• backup requirements
• restore testing
• continuity arrangements
• incident response
• escalation contacts
• tabletop exercises

Governance

• ISMS objectives
• policies
• risk register
• risk treatment plan
• Statement of Applicability
• compliance obligations
• metrics
• internal audit programme
• corrective actions
• management review

The result was not 84 independent compliance projects.

It was one management system.

An incident exercise revealed problems no policy review had found

Aegentra ran a tabletop exercise based on a realistic credential-compromise scenario.

A finance employee had apparently approved a malicious authentication request after receiving a convincing phishing message.

Participants included:

• IT;
• management;
• finance;
• HR; and
• communications.

The exercise asked practical questions.

Who disables the account?

Who checks sign-in activity?

Who determines what information the user could access?

When does management become involved?

Who assesses whether personal information was exposed?

Who contacts affected customers?

Who preserves evidence?

Who decides whether external notification is required?

The company had an incident-response policy.

The exercise nevertheless exposed unclear ownership between IT and management and an outdated external contact list.

Both were corrected.

The exercise also created something an auditor could examine: objective evidence that the incident-management process had actually been tested.

Evidence was designed while controls were being implemented

One of the biggest differences in the engagement was that evidence collection did not begin one week before the audit.

For each control, Aegentra established:

For Microsoft 365 controls supported by the Aeges assessment capability, current configuration evidence could be assessed read-only rather than relying solely on ageing screenshots.

For organisational, HR, supplier and operational controls, evidence remained tied to the actual business process.

The objective was simple:

If an auditor sampled a control, the organisation should be able to show what happened without reconstructing the story from memory.

Security objectives made the ISMS measurable

The company previously had an information-security objective:

Maintain a high level of information security.

It sounded appropriate but could not be measured.

Aegentra replaced broad intentions with defined measures.

Examples included:

• percentage of in-scope users meeting required MFA controls;
• privileged-access reviews completed on schedule;
• high-priority security remediation completed within agreed timeframes;
• security-awareness completion;
• critical supplier reviews completed;
• restore tests completed;
• security incidents reviewed;
• corrective actions overdue; and
• leaver access removed within the organisation's defined target.

These measures became inputs to management review.

Leadership could now see whether the ISMS was functioning instead of simply being told that the company was “compliant.”

A small 2024 requirement that many implementations overlook

The organisation's context review also considered the ISO/IEC 27001:2022 Amendment 1:2024 climate-action changes.

The purpose was not to invent a climate-related cybersecurity risk.

It was to explicitly determine whether climate change was relevant to the organisation's context and whether relevant interested parties had associated requirements.

For a cloud SaaS organisation, areas considered included supplier resilience, physical locations and continuity dependencies.

The decision and rationale were documented rather than ignored.

Source check: ISO published ISO/IEC 27001:2022/Amd 1:2024, titled “Climate action changes”, in February 2024.

Before certification: Aegentra deliberately stepped away from the internal audit

Aegentra had designed and implemented significant parts of the ISMS.

It therefore did not simply audit its own work and declare it satisfactory.

A separate objective and impartial internal-audit function reviewed the management system before certification.

The audit sampled:

• Clauses 4–10;
• risk assessment and treatment;
• Statement of Applicability;
• security objectives;
• access management;
• supplier management;
• incident management;
• backup and recovery;
• change management;
• awareness;
• monitoring;
• corrective actions; and
• selected Annex A control evidence.

Issues raised during internal audit were recorded as corrective actions and addressed before external certification.

That separation was important.

The purpose of an internal audit is not to prove the implementation team was right.

It is to find where the system is wrong before the certification body does.

Management review turned ISO 27001 into a leadership issue

Following the internal audit, management completed its formal ISMS review.

Leadership reviewed:

• outstanding risks;
• security objectives;
• incidents;
• internal-audit results;
• supplier issues;
• corrective actions;
• changes affecting the ISMS;
• resource requirements; and
• opportunities for improvement.

One important decision followed.

Several security responsibilities were still concentrated with the CTO.

Management approved redistribution of ownership across IT, engineering, HR and operational management.

The ISMS was no longer “the CTO's ISO project.”

It became an organisational management system.

Stage 1: could the system stand up on paper?

The independent certification body then conducted Stage 1.

The emphasis was readiness.

The organisation needed to demonstrate that its:

• scope;
• policies;
• risk methodology;
• risk assessment;
• treatment plan;
• Statement of Applicability;
• internal-audit arrangements;
• management review; and
• supporting documented information

formed a coherent management system.

Two readiness observations required additional evidence clarification before Stage 2.

Neither required redesigning the ISMS.

That was precisely why the implementation had treated Stage 1 as a readiness assessment rather than the finish line.

Stage 2: did the company actually do what its ISMS said?

Stage 2 changed the conversation.

The auditor sampled operational evidence.

Employees were interviewed.

Access records were inspected.

Risk treatment decisions were traced.

Training evidence was reviewed.

Supplier records were sampled.

Security events, changes and control activities were examined.

One minor nonconformity was identified.

During sampling, evidence for termination of access to one non-production SaaS system did not demonstrate completion within the timeframe established by the organisation's own procedure.

The account had been removed.

The problem was that the organisation could not demonstrate that it had happened within its defined target.

That distinction is important.

ISO 27001 audits do not only test whether security ultimately happened.

They test whether the management system operates as the organisation says it does.

Correcting the cause rather than fixing one record

The easy response would have been to correct the missing record.

Instead, the organisation performed root-cause analysis.

The cause was decentralised application ownership.

The corrective action therefore included:

1. updating the authoritative SaaS application register;
2. assigning an owner for every application;
3. connecting offboarding tasks to that register;
4. requiring evidence of completion;
5. adding overdue-access-removal escalation; and
6. testing another sample of leavers.

The certification body accepted the corrective-action response.

The organisation subsequently achieved ISO/IEC 27001:2022 certification.

What changed

Certification was the visible result.

The operational changes were more important.

Before

Security knowledge lived mainly in people's heads.

After

Responsibilities were assigned and documented.

Before

Security risks were broad statements such as “cyber attack.”

After

Risk scenarios connected assets, threats, impacts, treatments and owners.

Before

MFA existed.

After

Identity had a controlled lifecycle covering privileged access, devices, reviews and offboarding.

Before

Backups completed.

After

Recovery was tested and evidenced.

Before

Suppliers were reviewed primarily during procurement.

After

Critical suppliers were classified, assigned owners and reviewed according to risk.

Before

Policies described what should happen.

After

Evidence showed whether it actually happened.

Before

ISO 27001 belonged to IT.

After

Management reviewed objectives, residual risks, corrective actions and improvement.

Illustrative outcome dashboard

The most important lesson

The organisation initially believed ISO 27001 meant documenting its existing security controls.

The implementation showed something different.

ISO 27001 is the system that explains why those controls exist, who owns them, whether they work, what evidence demonstrates that they work, and what happens when they do not.

Technology mattered.

Conditional Access mattered.

MFA mattered.

Endpoint protection mattered.

Backups mattered.

Logging mattered.

But none of those controls alone created the ISMS.

The management system appeared when business context, risk, leadership, people, technology, evidence, audit and continual improvement started working together.

That was what made the organisation ready for certification.

What Aegentra did

For this illustrative engagement, Aegentra's implementation role covered:

• ISMS scope and context workshops;
• interested-party and obligation analysis;
• ISO/IEC 27001 gap assessment;
• information-asset mapping;
• information-security risk methodology;
• risk assessment and treatment planning;
• Statement of Applicability development;
• policy and procedure architecture;
• Microsoft 365 security remediation;
• identity and access governance;
• endpoint-security requirements;
• information protection;
• supplier-security governance;
• incident-response design and exercise;
• continuity and recovery evidence;
• security objectives and metrics;
• control ownership;
• evidence architecture;
• corrective-action support;
• management-review preparation; and
• certification-body evidence handover and readiness support.

Aegentra did not issue the ISO certificate.

Certification remained the decision of an independent accredited certification body.

And where Aegentra had materially implemented the ISMS, the Clause 9.2 internal audit was assigned separately so that appropriate objectivity and impartiality could be maintained.

Why this approach works

A useful ISO 27001 programme should leave the organisation with something more valuable than a certificate.

It should leave behind a repeatable answer to five questions:

1. What are we protecting?
2. What could realistically go wrong?
3. What are we doing about it?
4. How do we know those controls are operating?
5. What do we change when they are not?

When an organisation can answer those questions with evidence, ISO 27001 stops being a certification project.

It becomes part of how the company operates.

Considering ISO/IEC 27001 certification?

Aegentra helps Australian organisations define, implement and evidence ISO/IEC 27001:2022 information security management systems around their actual environment, risks and business requirements.

The implementation and the certification decision remain separate: Aegentra prepares the management system and evidence, while an independent accredited certification body performs the Stage 1 and Stage 2 certification audits.

Start with the scope, not the templates.