Manual penetration testing
Every assessment is run by an operator working the system the way an attacker would. Scanners find candidates; findings are ranked by what an attacker actually reaches.
Approach · Engagement process
Six steps, agreed before anything is touched.
- 01
Scope
We identify what is in scope, what is explicitly excluded, and what the engagement is meant to answer. Operational constraints come out here: maintenance windows, fragile systems, third-party hosting that needs its own permission, and any activity you do not want performed at all.
- 02
Rules of engagement
The rules of engagement record the testing window, the agreed intensity, the notification path for a serious finding, and the conditions under which testing pauses. Named escalation contacts are agreed on both sides before anything begins, so an out-of-hours question has an answer.
- 03
Written authorization
Testing starts only after written authorization is in place for the specific systems in scope. Where a system is hosted or operated by a third party, that provider’s own authorization requirements are confirmed first. No authorization, no testing.
- 04
Testing
Testing runs within the agreed boundaries. You are told about a critical finding when it is found, not when the report is delivered, and the engagement pauses if something unexpected puts availability or data at risk.
- 05
Reporting
The report is written twice over for two audiences: an executive summary that states risk and business impact in plain language, and technical findings with reproduction steps, evidence and remediation guidance for the team that owns the system.
- 06
Retest
One verification cycle for the agreed findings is included, within the period and scope defined in the statement of work. Retesting confirms whether the specific finding is resolved; it is not an open-ended second engagement.
How we work
Built around the team that owns the system.
Illustrative · security in practice
Retest, not just report
One verification cycle for the agreed findings, within the retest scope set in the statement of work, so you know what is actually fixed.
Written for two readers
An executive summary for the people who fund the fix, and technical findings with reproduction steps for the people who make it.
Critical findings, raised when found
You hear about a serious finding when it is found, through the escalation contact named in the rules of engagement — not at report delivery.
Scoped to your system
Scope, objectives and constraints are agreed before testing starts. If a smaller engagement answers the question, that is the one we propose.
What you receive
The report is the product.
A finding nobody can reproduce is not a finding. Everything is written to be acted on by the team that owns the system.
- Executive summary
- What was tested, what an attacker could reach, and what that means for the business — written to be read by people who will not read the technical findings.
- Technical findings
- Each finding with its affected component, the conditions required, a severity rationale, and reproduction steps a developer can follow.
- Evidence
- Requests, responses, configuration excerpts and screenshots that substantiate the finding, captured and handled under the terms agreed in the statement of work.
- Remediation guidance
- The change that removes the finding, at the level of the control rather than the single request, with a suggested order of work.
- Retest results
- The outcome of one verification cycle for the agreed findings, within the retest scope defined in the statement of work.
01 / Paperwork
Four documents, in plain language.
Each one does a different job, and an engagement needs all four. This is a description of how they are used, not legal advice — have your own counsel review the terms you sign.
- Master services agreement
- The commercial frame both parties sign once: confidentiality, liability, payment terms and how disputes are handled. It says nothing about what gets tested.
- Statement of work
- The engagement itself. Systems in scope, exclusions, dates, deliverables, the retest window, and the fee. If something is not written here, it is not in the engagement.
- Rules of engagement
- The operating instructions. Testing window, agreed intensity, which techniques are permitted, escalation contacts on both sides, and the conditions under which testing stops.
- Authorization to test
- Written permission from someone able to grant it, naming the specific systems. Where a system is hosted or operated by a third party, that provider’s own requirements are confirmed as well.
02 / Test data and findings
How engagement material is handled.
These are the operating commitments Red Cell makes in the statement of work. They are not a certification, and no accreditation is claimed for them. The specific retention period and deletion point are agreed per engagement rather than asserted here.
- Evidence capture
- Evidence is captured to substantiate a finding and no further. Where a finding can be shown without retaining customer records, it is shown that way, and sensitive values are redacted in the report.
- Storage and transfer
- Findings, evidence and reports are held in access-controlled storage and delivered over an agreed channel. The specific systems, retention period and deletion point are set in the statement of work for each engagement.
- Access
- Engagement material is available to the people working the engagement. Credentials issued for testing are returned or revoked at the end of the testing window.
- Disclosure
- A critical finding is reported when it is found, through the escalation contact agreed in the rules of engagement, rather than held until the report is delivered.
03 / Boundaries
What this does not cover.
Red Cell tests systems its clients own or are authorized to have tested. We do not test a third party because a client asks; the party that operates the system authorizes the work, in writing, first.
An engagement is a point-in-time assessment of an agreed scope. It does not certify a system, and it cannot show that no other issue exists — only what was found within the scope, the window and the constraints that were agreed.
Nothing here is legal advice. The service range is here, and scoping starts with a conversation about what you actually need demonstrated.
Tell us what you need to test.
Send the systems, the timing and the constraints. You get a scoped proposal, not a sales sequence.