Cybersecurity
Building a SOC: Build, Buy or Co-Manage?
The honest maths of 24x7 staffing, what a SOC really needs beyond a SIEM, and a framework for choosing between in-house, managed and co-managed security operations.
Key takeaways
- Start with the question the test must answer, not a list of IP addresses.
- Grey-box testing usually gives the best value for time spent.
- Rules of engagement protect both your operations and the testers.
- Compare quotes on effort, method and deliverables — not day rate alone.
Why scoping decides the value of a test
Two penetration tests with the same budget can produce radically different value. One examines the systems attackers would actually target, with enough time and access to go deep. The other skims a list of hosts and reports automated scanner output. The difference is almost always decided before testing starts — in the scope.
A good scope answers one question clearly: what do we need to know? Whether an external attacker can reach customer data, whether a compromised employee laptop can reach the domain controllers, whether a new mobile app can be abused to access other users' accounts. Each needs a different test.
Step 1: define the objective
- Assurance — confirming that a system is fit to go live or remains secure after change.
- Compliance — meeting a regulatory, contractual or certification requirement with defensible evidence.
- Attack simulation — testing whether a realistic adversary could achieve a specific goal, such as reaching payment systems.
- Detection validation — checking whether your monitoring and response teams would notice and act.
The objective determines everything else: which assets, which approach, how much time and what the report must say.
Step 2: list the assets precisely
Ambiguity in the asset list is the most common cause of disputes and disappointing results. Specify:
- External IP ranges and domains, confirmed as owned by you or authorised for testing
- Web applications by URL, including the user roles to be tested
- APIs, with documentation or a collection of requests
- Mobile applications and the platforms in scope
- Internal network segments and whether the test starts from a standard user device
- Cloud accounts or subscriptions, and whether configuration review is included
- Anything explicitly out of scope, with the reason
Step 3: choose the approach
| Approach | What the tester knows | Best for |
|---|---|---|
| Black box | Nothing beyond the target | Simulating an uninformed external attacker |
| Grey box | Credentials for defined roles and basic documentation | Most application and internal tests — the best balance of realism and depth |
| White box | Architecture, source code and configuration | High-assurance reviews of critical systems |
Black-box testing sounds realistic, but it spends much of a fixed budget on discovery that real attackers would complete over weeks. Grey-box testing lets testers spend their time finding and proving vulnerabilities.
Step 4: agree the rules of engagement
- Testing windows and time zones, including any blackout periods
- Whether production is in scope, and which actions are prohibited there — for example, denial-of-service or data modification
- Written authorisation from the asset owner, and from any third party hosting the systems where their policy requires it
- How sensitive data encountered during testing will be handled and deleted
- Named emergency contacts on both sides and a stop-testing procedure
- Whether your security operations team will be told in advance
Step 5: define reporting and retesting
Agree the deliverables before testing begins. A useful report contains:
- An executive summary written for non-technical leadership
- A findings register with severity, business impact and evidence
- Clear reproduction steps for each finding
- Prioritised, practical remediation guidance
- A retest of remediated findings within an agreed window
- An attestation letter where customers or auditors require one
How to compare quotes fairly
Day rate is the least useful comparison. Ask each provider for the effort in person-days per asset, the methodology they follow — such as the OWASP Web Security Testing Guide, PTES or NIST SP 800-115 — a sample report, the experience and certifications of the named testers, and whether retesting is included. A cheaper quote that allocates half the effort is not cheaper.
Common scoping mistakes
- Testing only what is easy to test. Excluding the systems that matter most because they are sensitive defeats the purpose; manage the risk with rules of engagement instead.
- Too little time for the scope. Compressing a complex application into two days produces scanner output, not a penetration test.
- Missing user roles. Authorisation flaws — one user reaching another's data — are among the most serious findings, and they can only be found with credentials for several roles.
- Forgetting APIs and mobile back ends. Many applications expose far more through their APIs than through their web interface.
- No plan for findings. Without owners and remediation deadlines agreed in advance, reports sit unread and the same issues reappear next year.
Frequently asked questions
How often should we run a penetration test?
At least annually for important systems, and after any significant change. Regulated organisations should follow the frequency set by their regulator or framework.
Can penetration testing be run safely against production?
Yes, with appropriate rules of engagement. Experienced testers avoid destructive actions, and high-risk steps can be agreed in advance or performed in a staging environment.
What is the difference between VAPT and a penetration test?
VAPT combines broad vulnerability assessment, largely automated with expert validation, with manual penetration testing that exploits and chains findings to show real impact.
NAZZTEC Editorial TeamWritten and reviewed by NAZZTEC practitioners. This briefing is general guidance, not legal advice.
