What did a pentester find within 30 minutes of entering the network? Common organisational mistakes

09:00. An agreed penetration test begins. The tester knows the scope, rules and contacts. They first build a picture of the environment and check whether organisational assumptions match reality.

By 09:30, several areas need verification: an unnecessary service, broad privileges, weak network separation and an account without additional authentication. These do not prove a breach, but indicate greater risk than the documentation suggested.

Can all this be spotted so quickly? Sometimes, yes: penetration testing starts with methodical observation, comparing reality with assumptions and selecting hypotheses for safe validation.

Useful insights

• A penetration test is an authorised, controlled security assessment. Scope, permitted activities, communication and stop conditions are agreed beforehand.
• The first 30 minutes do not necessarily confirm a critical vulnerability. However, they may reveal discrepancies in inventory, configuration, access or segmentation.
• The greatest risk rarely comes from a single spectacular flaw. It can arise from combining several seemingly minor weaknesses.
• Penetration tests, security audits and vulnerability scans answer different questions. In a mature programme, they complement each other.
• A report delivers value when findings receive owners, deadlines and priorities and are rechecked after remediation.

The first 30 minutes of a penetration test

The timeline is an illustrative scenario, not a description of a VigilHorizon customer or engagement. It contains no exploits, commands or details facilitating attacks.

09:00 — testing begins with the rules

The tester confirms systems, test accounts, exclusions, the testing window and communication. If a service is affected or an important finding emerges, it is clear who decides whether to continue or stop. Inconsistent system lists, unknown owners and outdated contacts are not technical vulnerabilities, but reveal operational risk.

09:12 — the initial picture of the environment emerges

The tester compares scope with visible assets and dependencies. A service left after migration, an unrecorded system or an interface more widely accessible than expected may emerge. This does not prove exploitability, but highlights issues in documentation, change management and exposure control.

09:20 — individual observations begin to form a context

Potential risks appear: inconsistent access, missing MFA, broad visibility between segments or an outdated service. The tester asks what asset the control protects and what the impact would be. Missing MFA means something different for a test account than for a critical-service administrator; an outdated component may be less urgent if effectively isolated.

09:30 — hypotheses are ready for safe verification

After 30 minutes, there are no final conclusions, but a map of access, segmentation, updates, services and identities requiring deeper analysis. Hypotheses must be validated within authorisation and proportionately to risk. A full test takes longer; the first half-hour shows where to look.

Where a penetration test begins

A professional test begins before the assessment. Both parties agree the objective, scope, success criteria and Rules of Engagement: systems, exclusions, hours, load limits, data handling, emergency contacts and stop conditions.

The tester acts with the owner’s consent and within agreed boundaries. For production, legacy devices or load-sensitive services, the rules must reflect their characteristics. 'Test everything’ is not a safe scope.

NIST SP 800-115 describes technical testing as a process covering planning, execution, result analysis and follow-up. The key organisational lesson is that quality depends on preparation and the use of results, not only the technical phase (NIST, Technical Guide to Information Security Testing and Assessment).

Before starting, establish the supported process, unacceptable impact, decision owner, urgent-finding escalation and rules for protecting and deleting evidence.

What can be noticed in the first minutes

The early stage is about finding where reality diverges from policies, documentation or expectations, rather than collecting warnings. Typical observations include:

• services or interfaces unnecessary within the agreed scope;
• environmental components missing from the current inventory;
• configurations inconsistent with organisational standards;
• accounts or roles with more access than their tasks justify;
• uneven MFA coverage;
• weak separation between areas of differing criticality;
• components requiring a review of currency and vendor support;
• gaps in logging, system ownership or escalation procedures.

Observation category	Business question	Potential impact	Safe next step
An asset missing from the inventory	Who owns the system and its updates?	an unseen component may fall outside maintenance and monitoring	confirm the owner, purpose and lifecycle
Excessive privileges	Does access match the user’s actual role?	greater impact after loss of account control	review roles and apply least privilege
Missing MFA for selected access	Which critical functions does this account protect?	weaker identity-layer resilience	apply MFA and review exceptions
Inconsistent segmentation	Should systems of different criticality communicate?	easier expansion of incident impact	verify flows and separation rules
An outdated service	Is the component supported and necessary?	known weaknesses or unavailable fixes	update, retire or apply a compensating control
Missing appropriate logs	Would the organisation notice misuse?	delayed detection and harder incident investigation	add data sources and monitoring scenarios

No row alone proves a critical threat. Validation distinguishes an actual weakness from a signal of limited significance.

Common problems found during penetration testing

Excessive privileges

Privileges accumulate as roles and projects change. New access is granted without removing previous access; service accounts gain access to more systems. A penetration test checks whether that scope still matches the need.

Missing segmentation or rules inconsistent with the design

Documentation may show separate zones, yet migration, integration or permanent exceptions allow broader flows. An incident in a less critical area can then affect a more important system.

Outdated systems and unnecessary services

An older version does not automatically mean exploitability, and an available service is not necessarily unnecessary. The problem is missing ownership, justification, exposure assessment or compensating controls.

Weak access control and MFA exceptions

An organisation may claim MFA coverage while retaining exceptions for accounts, integrations or administration. Testing assesses their significance in the agreed scenario, rather than merely marking MFA present or absent.

Microsoft 365 configuration errors

In Microsoft 365, relationships between roles, access policies, sharing, applications and exceptions matter. Configuration must be assessed against working practices, data criticality and administration.

Initial findings are not a league table of IT failures. They map assumptions worth checking before an attacker connects them. Organisational maturity is demonstrated through prioritisation and remediation, not promises of flawlessness.

Illustrative case study: three small gaps, one larger problem

A fictional service company commissions a test of part of its network. Within 30 minutes, the tester sees an account with an overly broad role, an old service left after migration and missing MFA for selected administrative access.

Individually, each finding appears manageable in the normal cycle. Together, they reveal weaker boundaries and greater consequences from losing one account than expected.

The tester limits proof to the agreed minimum. The company removes the service, restricts the role, closes the MFA exception and reviews similar accounts and segmentation. Retesting confirms the changes. This is an editorial example, not a VigilHorizon customer case.

Testing identifies improvements before an attacker does. Its value is measured by decision quality, not impressive findings.

Why organisations miss these problems

Gaps accumulate over years of applications, integrations, supplier accounts and exceptions. Each change may be justified, but their sum creates an environment nobody designed as a whole.

The first factor is familiarity. The team remembers why access was opened, but checks less often whether the reason still applies. An external reviewer asks for evidence of the current need.

The second is fragmented responsibility. Infrastructure, Microsoft 365, applications and networks have different owners, each seeing only a part. Penetration testing reveals dependencies, while IT security audit provides a broader assessment of processes, architecture and roles.

The third is equating a lack of reports with a lack of problems. Without measuring log coverage and alert handling, a company cannot know whether it would notice misuse. Testing can also assess whether actions are visible to monitoring and the SOC.

What happens after a vulnerability is found

A finding must be verified, documented to the necessary extent and assessed for impact and mitigating controls. Automated severity is insufficient without business-process context.

Finding	Potential risk	Recommended action
Excessive privileges	broader access after loss of account control	review roles, remove unnecessary access and recertify periodically
Missing MFA for an important account	weaker identity and administrative-access protection	deploy MFA; review exceptions and recovery paths
Missing segmentation	incident impact spreading between systems	review necessary flows, segment and test rules
An outdated system	possible known weaknesses or lack of support	update, migrate, retire or apply a compensating control
An unnecessary service	an unnecessarily larger attack surface	confirm its purpose and disable safely
Inconsistent Microsoft 365 configuration	excessive sharing or broader privileges	review roles, access policies and applications

Priority combines feasibility, asset value and impact. A medium-severity finding may be urgent for a critical system, while a technically serious issue may be less pressing because of isolation and additional controls.

At VigilHorizon, a recommendation should answer four questions: what should change, who owns it, by when and how will effectiveness be confirmed? Without this, a report can become technical notes with no effect on risk.

Penetration testing, auditing or vulnerability scanning

These activities are not interchangeable. Scanning gives a broad view of potential weaknesses, penetration testing validates scoped scenarios, and auditing assesses the wider system of controls, processes and responsibilities.

Criterion	Vulnerability scanning	Penetration testing	Security audit
Main question	What potential weaknesses does the tool identify?	What can be confirmed, and what could the impact be?	Are controls and processes appropriate and effective?
How we work	primarily automated and recurring	tools plus manual expert analysis	review of evidence, configuration, architecture and processes
Outcome	a list of items to validate	confirmed findings, scenarios and recommendations	gaps, risk assessment and an improvement plan
Business context	depends on the analysis process	high when the scope is clearly defined	broad, covering technology and the organisation
Typical cycle	regularly and after changes	periodically and after significant changes	according to risk, requirements and management cycles
Limitation	false positives and weaker understanding of relationships	results limited to the test scope and point in time	not every weakness is actively validated

The differences are discussed in Penetration testing — how does it differ from vulnerability scanning?. For web applications, a reference is the OWASP Web Security Testing Guide, but a methodology does not replace an individually agreed scope.

Penetration testing supports assessment of control effectiveness, but does not establish full NIS2 compliance, which also covers risk, incidents, continuity, suppliers and documentation. Learn more: NIS2 compliance audit — how to prepare your organisation.

Why penetration testing does not end with a report

A report describes a specific time and scope, not permanent security. Its findings must feed vulnerability management as updates, migrations and roles change.

A practical cycle includes:

1. confirming and classifying findings;
2. assessing impact on processes and data;
3. assigning an owner and deadline;
4. choosing remediation or a documented compensating control;
5. implementing the change in a controlled way;
6. retesting the most important findings;
7. updating standards, monitoring and team knowledge.

Retesting checks that a fix resolves the finding without creating another gap. Architectural changes may require broader dependency verification.

Results should also improve visibility: logging, correlation and escalation. SOC 24/7 does not replace penetration testing, but can use its findings to improve detection and playbooks.

How to prepare your organisation

Define the objective instead of ordering a test of everything

The objective should address risk: application resilience, standard-account security, environmental separation or critical data. The provider can then choose the appropriate model.

Keep scope and ownership current

An address list is insufficient. Systems, domains, suppliers, exclusions and owners are needed. Production requires constraints protecting continuity.

Prepare communication and response

Contacts must be available during testing. Urgent findings should not wait for the report. Establish who can change scope, stop testing or initiate incident handling.

Combine the activities into one programme

Scanning finds known weaknesses, penetration testing validates scenarios, auditing assesses the system, training reduces mistakes and the SOC supports detection. VigilHorizon connects findings with owners, deadlines and retesting.

Check readiness before starting

• Does the scope cover the most important processes and systems?
• Are prohibited activities and stop conditions documented?
• Do technical and business owners know the assessment date?
• Are emergency contacts available on both sides?
• Are evidence protection, retention and deletion agreed?
• Is it clear how quickly a critical finding should be communicated?
• Will the report include impact, recommendations and priority?
• Are remediation owners and retesting planned?

Summary

The first minutes of a professional penetration test often reveal more than an organisation expects, not because its infrastructure must be unusually weak, but because exceptions, access, integrations and changes accumulate until they no longer form a coherent security model.

Penetration testing provides controlled conditions, authorisation, scope and safe validation. It is not a demonstration of the tester’s superiority. It determines which weaknesses are real, how they combine, which business processes are exposed and what to fix first. A report closes the assessment stage; implemented changes and retesting confirm risk reduction.

If you are unsure whether documentation matches the actual environment, whether MFA exceptions remain necessary or whether segmentation works as designed, start by defining the assessment objective. VigilHorizon can help select penetration testing, a security audit or an NIS2 compliance assessment appropriate to critical processes and current risk. The starting point is an analysis of organisational scope and needs, not one predefined scenario imposed on every company.

Frequently asked questions (FAQ)

1. Does a penetration test mean attempting a break-in?​

It is an authorised, controlled assessment of scenarios. The tester acts with organisational consent and under safety rules. The objective is to validate risk with limited impact, not to gain access at any cost.

2. What can a tester find in the first 30 minutes?​

They may identify unrecorded assets, inconsistent configurations, unnecessary services, excessive privileges, MFA exceptions or weak segmentation. This does not establish that every issue is exploitable.

3. How long does a penetration test take?​

Duration depends on the objective, scope, system count, model and limitations. The first 30 minutes are a narrative frame; a full assessment requires further validation, documentation and impact analysis.

4. Is penetration testing safe?​

Scope, Rules of Engagement, exclusions, contacts and stop conditions reduce risk. They cannot eliminate it, particularly in production.

5. How does a penetration test differ from vulnerability scanning?​

Scanning automatically identifies potential weaknesses. Penetration testing manually and controllably validates selected scenarios and their significance. The two complement each other.

6. How does a penetration test differ from an IT security audit?​

A penetration test actively checks resilience within a specific scope. An audit may assess architecture, configurations, processes, documentation, roles and compliance more broadly. Audits do not always actively validate scenarios, and penetration tests do not automatically assess the entire organisation.

7. How often should penetration testing be performed?​

Frequency should follow risk. Testing is particularly appropriate after significant architectural changes, critical-system deployment, migration, identity-model changes, incidents or major exposure changes. Regular scanning should occur more frequently than in-depth penetration testing.

8. Is penetration testing required by NIS2?​

NIS2 does not reduce obligations to one test or tool. Penetration testing can help assess selected controls, but does not replace overall risk management, incident handling, business continuity, supply-chain security and documentation.

9. Does finding no critical vulnerabilities mean a system is secure?​

No. The result applies to a particular time and scope. Several lower-severity findings may form an important scenario, and out-of-scope areas were not assessed. Context, dependencies and limitations matter.

10. What should a good penetration test report contain?​

Scope, limitations, methodology, confirmed findings, necessary evidence, business impact, priorities and recommendations. Action ownership, closure criteria and a proposed retest scope are also useful.

11. Is retesting needed after remediation?​

Yes, especially for high-impact findings and changes affecting multiple systems. Retesting confirms the fix resolves the problem in the actual environment. A task marked closed is not proof of effectiveness.

12. How should a company prepare for its first penetration test?​

Define the objective and critical processes; prepare an up-to-date scope, exclusions, owners and contacts. Agree test-data protection, escalation, stop criteria, report format, prioritisation and a retest date.

Learn more

• Penetration testing — how does it differ from vulnerability scanning?
• IT security audits — what do they cover, and when are they useful?
• NIS2 compliance audits — how should an organisation prepare?
• What is SOC 24/7, and why is monitoring not enough?
• SIEM in your company — why deployment alone does not improve security