Penetration Testing / Security Assessments
Authorized, scoped security testing for web apps, APIs, and infrastructure
RedShaw Consulting runs penetration tests and security assessments under written scope and written authorization. Manual testing sits alongside automated tooling, findings are ranked by risk, and every issue arrives with reproduction steps, evidence, and remediation guidance a development team can actually act on.
Who this is for
For teams that are responsible for someone else’s data
This service is for organizations holding client, user, or payment data that need an independent, methodical look at how their systems hold up under pressure.
SaaS teams
Multi-tenant products where account isolation, permission boundaries, and API behavior matter as much as the login page.
Agencies
Teams delivering sites and platforms for clients who need testing they can commission on a client’s behalf, with clear scope and reporting they can hand over.
Businesses handling payment data
Companies processing payments or storing financial details that need an independent assessment before, during, or after a build.
Businesses handling client records
Practices and platforms holding confidential client, patient, or customer records, where exposure is the primary risk rather than downtime.
Problems this solves
Security problems this solves
Never independently tested
The application was built, reviewed internally, and shipped, but nobody outside the team has genuinely tried to break it.
Scanner output, no judgment
A tool report exists, but nobody has chased the logic flaws, permission gaps, and multi-step issues that scanners do not find.
Unproven tenant boundaries
The product separates accounts in theory, but no one has demonstrated that one tenant cannot reach another tenant’s data.
An API surface that grew quietly
Endpoints added over time now do more than the documented product, and the authorization rules behind them are no longer clear to anyone.
A customer or partner is asking
A prospect, insurer, or enterprise buyer wants evidence that the platform has been security tested by someone independent.
Findings with no path to a fix
Previous reports listed issues without reproduction steps, evidence, or guidance the development team could use.
What RedShaw does
Manual testing alongside automated tooling
Tooling is used where tooling is good: coverage, enumeration, dependency issues, and known vulnerabilities. The findings that matter most usually come from working through the application by hand.
- Manual testing of application logic, authentication, session handling, and permission boundaries.
- Automated tooling for coverage, enumeration, dependency issues, and known vulnerabilities.
- API testing across authorization, input handling, rate limiting, and object-level access.
- Multi-tenant isolation testing, where one account should never be able to reach another account’s data.
- Infrastructure and configuration review within the agreed scope.
- Findings ranked by risk, so the team knows what to fix first instead of facing a flat list.
- Reproduction steps and evidence for every finding, written so a developer can confirm it independently.
- Remediation guidance that describes the fix, not just the symptom.
- Retest on request once fixes are in place.
How engagements work
How a security engagement runs
1. Written scope and authorization
Nothing is touched until targets, timing, contacts, and limits are agreed in writing, and the organization that owns the systems has authorized the work in writing.
2. Testing
Manual testing alongside automated tooling across the agreed targets. A named contact is kept informed, and anything serious is raised immediately rather than held back for the report.
3. Report
Findings ranked by risk, each with reproduction steps, evidence, affected components, and clear remediation guidance.
4. Remediation support
Time to walk the team through the findings, answer questions while fixes are being built, and help judge sequencing and tradeoffs.
5. Retest
On request, a focused retest to confirm the fixes hold and to check that the change did not introduce something new.
Ongoing testing where it fits
Some platforms need more than a point-in-time test. Testing can continue on an agreed cadence as the product changes, rather than ending at the report.
What you get
A report the development team can work from
The deliverable is written to be used, not filed. Every finding should be reproducible by the team that has to fix it.
Risk-ranked findings
Issues ordered by real risk to the business and its data, so remediation starts with what matters rather than what was found first.
Reproduction steps
Step-by-step detail for each finding, so a developer can confirm the issue and confirm the fix without guessing.
Evidence
Supporting evidence recorded for each finding, kept to what is needed to demonstrate the issue.
Remediation guidance
A practical description of the fix and where it belongs, informed by what it takes to ship it in a real codebase.
Background and authorization
Two decades across infrastructure, security, and web development
RedShaw Consulting is led by Gareth Redfern-Shaw, with two decades of work spanning infrastructure, security, and web development. That background is why findings arrive with a fix attached rather than a label.
Written authorization, every time
Testing starts only once the organization that owns the systems has authorized it in writing, with scope and limits recorded. There are no informal go-aheads.
Responsible disclosure
Where testing identifies something serious, it is reported privately and directly to the organization responsible, with enough detail to act on. Nothing is published.
Close to the build
The same practice builds and maintains web applications and infrastructure, so remediation advice is grounded in what it takes to ship the fix.
Sustained testing, not just a scan
RedShaw has tested a live multi-tenant SaaS platform continuously across more than twelve months, reporting over 400 issues through a disciplined disclosure process.
Scope and honesty
What this service does not claim
Not a certification
RedShaw does not issue compliance certificates or accreditation. The deliverable is a technical assessment of an agreed scope, not a badge.
Not a guarantee
A penetration test is a point-in-time assessment. It reduces risk and finds real problems, but no test can prove an application is free of issues.
Not unauthorized testing
RedShaw does not test systems without written authorization from the party that owns them, whatever the commercial pressure to move faster.
Not a scanner report with a cover page
Automated output is a starting point. If a finding cannot be reproduced and explained, it does not go in the report as a finding.
RSC Suite connection
How RSC Suite thinking supports security work
RSC Suite is the internal platform and methodology behind RedShaw content, SEO, analytics, and workflow work. It is built as a multi-tenant system, which means tenant isolation, permission boundaries, audited reads, and controlled deployment are daily engineering concerns rather than unfamiliar territory.
That matters for testing work in two practical ways. Multi-tenant isolation testing is familiar ground rather than an unusual request. And because the same practice builds and operates this kind of system, remediation guidance is written with an understanding of what the fix will cost the team that has to make it.
Related services
Connected support when the work goes further
Technical Consulting
Plan practical workflows, integrations, platform choices, and operational tools. Learn more.
Fractional CTO / Technical Advisory
Senior technical judgment for platform, vendor, and architecture decisions. Learn more.
WordPress / Avada Development
Builds, rebuilds, cleanup, and maintainable WordPress and Avada systems. Learn more.
Website Development
Plan and build a clearer site with stronger structure, messaging, and conversion paths. Learn more.
RSC Suite
See the internal platform and methodology behind RedShaw systems work. Learn more.
Contact
Start a practical conversation about scope, targets, and timing. Learn more.
FAQ
Common questions
Do you need written authorization before testing?
Yes, always. Scope, targets, timing, contacts, and limits are agreed in writing, and the organization that owns the systems authorizes the work in writing before anything is touched. This protects both sides and it is not negotiable.
Can an agency commission testing for a client?
Yes. The authorization still has to come from the party that owns the systems, but the engagement can be scoped, managed, and reported through the agency.
Can you test a live production system?
Often, yes, with agreed limits around timing, rate, and any destructive testing. Where production risk is too high, testing can run against staging with the differences noted in the report.
How long does an engagement take?
It depends entirely on scope: the size of the application, the API surface, the number of roles and tenancy boundaries, and whether infrastructure is included. Scope and timing are agreed in writing before work starts, so there are no open-ended estimates here.
Do you retest after we fix the findings?
Yes, on request. A retest confirms the fixes hold and checks that the change did not introduce something new.
What happens if you find something critical mid-test?
It is reported to your named contact immediately rather than held back for the report, with enough detail to act on straight away.
Will you name us as a client?
Only with your written agreement. Security work is published anonymously by default, and engagement detail stays confidential.
Start a conversation about testing your platform
If your business holds client, user, or payment data and nobody independent has tested the platform, the first step is a scoping conversation: what the systems are, what matters most, and what testing would sensibly cover.