Security check or penetration test: Which assessment fits?

Start with the assessment objective

Do you need to understand which systems are visible from the internet, which configurations deserve attention and what to address first? An external security assessment is a useful starting point. If the question concerns an application's roles, data access or business workflows, the engagement needs the corresponding penetration testing depth.

Company size does not determine that choice. An international IT provider may need a focused external review of one domain. A small software business may need a detailed assessment of its customer portal. Put the decision before the list of methods: what should we be able to decide more confidently after this work?

NIST describes security testing as a planned process involving suitable methods, analysis and mitigation. A service name by itself therefore says little about the agreed scope. [1]

Compare the scope directly

This comparison helps frame an engagement. Cyberkern agrees the precise scope around the systems and questions involved.

A customer portal needs more than an external check

A valid TLS certificate does not establish whether customers can access only their own documents. Meaningful authorisation testing compares permitted access using different test identities. OWASP recommends several users with separately owned test objects.

For an IT provider or consultancy running a customer portal, split the questions clearly: identify the public services, then examine the relevant roles and customer boundaries. These activities can be commissioned separately. Their value comes from the questions answered, rather than the number of testing terms listed in a proposal. [2]

Prepare roles and tenant boundaries for authorisation testing

Compare proposals using five questions

Two proposals become comparable when they address the same objective with similar prerequisites. For a package described only in general terms, ask for these details:

• Which domains, applications, interfaces and environments are included?
• Which tests are planned, and which activities are excluded?
• Which information, test accounts and responsible contacts must be available?
• What evidence, actions and unresolved questions will the report contain?
• How will corrections, questions and any retesting be agreed?

What makes a security report useful for the people implementing changes

For IT providers: Agree responsibilities early

When systems are operated for customers, the commissioning organisation, system operator and technical contact must align. Record who controls each domain, who authorises the assessment and who may make changes. A hosting contract or administrative account does not always describe those responsibilities completely.

Also record which customers or projects depend on the systems being assessed. A shared service can affect several engagements, while an isolated project may concern a much smaller area. This mapping helps assign actions to the right owner and reduces avoidable clarification after the report arrives.

Build a usable inventory of domains, services and owners

Begin with a short enquiry

For an initial enquiry, provide the objective, the domains or applications involved and your preferred timeframe. Passwords and confidential customer documents do not belong in the contact form. Cyberkern agrees the detailed scope before an engagement begins. You can therefore start the discussion without having to write a complete technical specification first.

Related reading

• External attack surface: inventory your domains and services
• Testing access control and tenant isolation
• Reading a security report: Turn findings into action