Web application findings
Examples may include:
- Authentication weaknesses
- Authorization failures
- Session security issues
- Input validation weaknesses
- Business logic vulnerabilities
- Sensitive data exposure
- Security misconfigurations
INDEPENDENT REMEDIATION VALIDATION
Your team fixes it.We prove it’s fixed.
CyberCile independently tests remediated security findings to determine whether the original condition has been corrected, whether reasonable bypasses remain, and what evidence supports the result.
Independent testing • Manual validation • Clear outcomes • Closure evidence
No long-term commitment required.
- FOUND
- FIXED
- VERIFIED
- EVIDENCE
Verification is a testing outcome, not an automatic next status. Evidence records the actual result.
THE VERIFICATION GAP
A closed ticket tells you work was completed.
It doesn't tell you whether the attack still works.
Security findings often move through a familiar process:
A vulnerability is discovered.
Engineering implements a fix.
The ticket is marked resolved.
A scanner stops reporting the condition.
But those signals answer different questions.
"Resolved" describes workflow status.
"Not detected" describes what a tool observed.
Neither independently demonstrates that the original security condition can no longer be exploited.
CyberCile adds the missing step:
Independent verification.
- FOUND
- FIXED
- VERIFIED
- EVIDENCE
"Resolved" is a status. Verified is a result.
WHAT WE RETEST
Already have findings? Start there.
CyberCile can independently validate eligible remediated security findings whether they originated from a penetration test, security assessment, vulnerability scanner, internal security team, customer review, or another security provider.
API findings
Examples may include:
- Broken object-level authorization
- Broken function-level authorization
- Authentication weaknesses
- Token handling issues
- Excessive data exposure
- Rate-limit weaknesses
- Input manipulation
- Business logic abuse
Infrastructure findings
Eligible findings may include security conditions that can be safely and defensibly reproduced within the agreed environment and rules of engagement.
Other findings
Some findings may require specialized testing, additional access, source code review, cloud configuration review, social engineering, physical access, or other services outside standard remediation validation.
Eligibility should be confirmed before testing begins.
THE CYBERCILE METHOD
We don't just rerun the original check.
01 / REVIEW
Understand the finding
Review the original finding, affected system, exploitation path, supporting evidence, remediation information, and expected security behavior.
02 / REPRODUCE
Recreate the condition
Where feasible, reproduce the original security condition to establish a defensible baseline before evaluating the fix.
03 / VALIDATE
Test the remediation
Manually test the implemented correction against the original vulnerability and expected security control.
04 / CHALLENGE
Look for bypasses
Attempt reasonable alternate paths, edge cases, or bypasses relevant to the original finding and remediation.
05 / CLASSIFY
Determine the result
Assign a clear validation outcome based on what the testing demonstrates.
06 / PROVE
Return the evidence
Document the validation result and supporting evidence so the outcome can be understood and defended.
CLEAR RESULTS
Not every fix ends with "pass" or "fail."
Security remediation can produce several legitimate outcomes. CyberCile uses explicit classifications so the result is not hidden behind a closed ticket.
- VERIFIED
- The remediation successfully addresses the tested security condition.
- PARTIALLY FIXED
- The remediation improves the condition, but exploitable behavior or meaningful risk remains.
- NOT FIXED
- The tested security condition remains exploitable.
- UNABLE TO VERIFY
- The environment, access, evidence, technical condition, or another limitation prevents a defensible validation result.
- RISK ACCEPTED
- The organization has formally chosen to retain the identified risk rather than remediate it.
Risk Accepted is not equivalent to Verified. A Verified result applies only to the tested finding and tested security condition. It does not certify that the entire application or environment is secure.
CLOSURE EVIDENCE
Don't just close the finding. Keep the proof.
For each eligible validated finding, appropriate documentation may include:
- Original finding reference
- Affected system or asset
- Validation date
- Validation methodology
- Original condition tested
- Remediation tested
- Validation result
- Supporting technical evidence
- Relevant observations
- Remaining risk where applicable
- Testing limitations where applicable
- Recommended next action where applicable
The objective is to create a defensible record of what was tested and what the testing demonstrated.
Evidence requirements vary by requester. Confirm what your customer, bank, auditor, or other stakeholder needs; validation evidence does not automatically satisfy every requirement.
We didn't find the vulnerability. Can we still validate the fix?
Yes, when the finding provides enough information to test defensibly.
CyberCile does not need to have performed the original penetration test to independently validate an eligible remediated finding.
We begin by reviewing the original finding and available evidence.
Useful information may include:
- Finding title
- Affected asset
- Technical description
- Original reproduction steps
- Proof of concept
- Screenshots or request/response evidence
- Severity
- Original report excerpt
- Remediation notes
- Relevant access or test accounts
If the original finding does not contain enough information to reproduce or evaluate the condition, CyberCile will identify what is missing before claiming a validation result.
Independent validation means we evaluate the evidence and the remediation ourselves.
We do not inherit another provider's conclusion.
GETTING STARTED
Start with the finding, not a sales presentation.
- Original finding or report excerpt
- Affected system or asset
- Available reproduction information
- Remediation description
- Testing environment
- Required test access
- Relevant credentials or test accounts
- Testing restrictions
- Target deadline
- Any evidence requirements you already know about
The checklist is for secure exchange after qualification. Initial intake below asks only for contact details, categories, and timing.
Do not send passwords, production secrets, API keys, customer data, or other sensitive credentials through an unsecured intake form.
Secure exchange procedures should be provided after initial intake.
Which type of testing do you actually need?
Scanner retest
- Best question answered
- Does the tool still detect the condition?
- Typical approach
- Automated re-scan.
- Useful for
- Known signatures, configuration checks, broad vulnerability hygiene.
Independent Remediation Validation
- Best question answered
- Does the implemented remediation actually address the tested security condition?
- Typical approach
- Human-led retesting of a known finding, including reasonable bypass testing where appropriate.
- Useful for
- Verifying remediation and documenting closure evidence.
Penetration test
- Best question answered
- What exploitable weaknesses and attack paths exist across the defined scope?
- Typical approach
- Broader adversarial testing across applications, APIs, infrastructure, or other agreed systems.
- Useful for
- Discovering and validating security weaknesses across a defined attack surface.
If you already know the finding and need to verify the fix, remediation validation may be enough.
If you need to discover what else is vulnerable, you probably need broader security testing.
Explore Penetration Testing →WHEN TO USE IT
Independent validation fits several security workflows.
After a pentest
Your team remediated findings and needs independent verification before closure.
After a vulnerability assessment
A scanner or assessment identified a condition that requires human validation after remediation.
Before a customer security review
You want stronger evidence supporting the status of previously identified findings.
Before a bank or partner review
Previously identified material findings need defensible remediation status.
After internal security testing
Your internal team found and remediated an issue, but you want independent verification.
After another security provider's test
The original tester is unavailable, retesting is not included, or independent verification is preferred.
For msp / mssp clients
Your team coordinates remediation for clients and needs an independent party to validate closure.
FOR MSPs, MSSPs & SECURITY PARTNERS
Add independent verification without building another testing team.
Your team manages the client relationship and remediation process.
CyberCile provides the independent validation layer.
Your team fixes it. We prove it’s fixed.
- Submit eligible remediated findings.
- CyberCile reviews the original evidence and remediation information.
- CyberCile performs independent validation.
- Findings receive a documented validation outcome.
- Supporting evidence is returned for client closure.
- MSPs
- MSSPs
- Compliance consultancies
- vCISO providers
- Security consultancies
- Technology providers managing client remediation
No long-term commitment required.
Sometimes you need more than a retest.
Independent Remediation Validation is designed to answer a narrow question:
Did this remediation address this known security finding?
You may need a penetration test when:
- You do not know what vulnerabilities exist.
- The application has materially changed.
- A major release introduced new attack surface.
- The original assessment was narrow or outdated.
- You need broader adversarial testing.
- You need to evaluate multiple attack paths beyond known findings.
You may need 90-Day Financial Systems Security Assurance when:
- You have multiple applications or APIs.
- Testing and remediation will happen continuously.
- You need support moving findings through remediation.
- You need independent verification throughout the engagement.
- You need a broader evidence package.
- You are working toward a defined security objective over the next 90 days.
WHY CYBERCILE
Independent means we test the result.
CyberCile approaches remediation from the attacker's side.
The question is not whether a ticket was closed.
The question is whether the security condition still works.
- Human-led validation
- Ethical hacker-led methodology
- Independent verification
- Reasonable bypass testing
- Clear validation outcomes
- Evidence-backed closure documentation
- Attack-path perspective
Frequently Asked Questions
Can CyberCile retest a vulnerability it did not originally find?
Yes, for eligible findings with enough original evidence, remediation context, access, and authorization to test defensibly. CyberCile reviews the evidence independently rather than inheriting the original provider’s conclusion.
What information do you need to validate a finding?
The original finding reference, affected asset, technical description, available reproduction steps and evidence, remediation notes, testing environment, restrictions, and deadline help define scope. Initial intake collects only qualification details. Technical evidence and test credentials use the agreed secure exchange process after qualification.
Do you need the original penetration test report?
A relevant report excerpt and supporting evidence may be sufficient. The complete report is not always necessary. CyberCile reviews whether the available information supports a defensible test and identifies missing details before testing begins.
Can you validate scanner findings?
Eligible scanner findings can be validated when the security condition can be meaningfully and safely tested. A scanner is useful for detecting known conditions; human validation evaluates whether the implemented remediation addresses the relevant condition and reasonable bypasses.
What if you cannot reproduce the original vulnerability?
CyberCile reviews the available evidence, system changes, access, and testing limitations. If these do not support a defensible result, the outcome is Unable to Verify. Failure to reproduce a condition is not automatically proof that it was fixed.
What does Partially Fixed mean?
The change improves the original condition, but exploitable behavior or meaningful risk remains. CyberCile documents the remaining issue, relevant evidence, and recommended next action.
What happens if the vulnerability is still exploitable?
The finding is classified as Not Fixed when the tested security condition remains exploitable. CyberCile documents the result and supporting evidence so the responsible team can decide the next remediation step.
Do you test for bypasses?
Where appropriate and within the authorized scope, CyberCile attempts reasonable alternate paths, edge cases, or bypasses relevant to the original finding and its remediation. This does not promise exhaustive testing of every possible attack path.
Does remediation validation include finding new vulnerabilities?
Validation focuses on the known finding and reasonable bypasses relevant to its remediation. Broader vulnerability discovery requires penetration testing or another appropriately scoped assessment. A Verified result applies only to the tested finding and security condition, not the entire system.
How is remediation validation different from a penetration test?
Validation asks whether a specific remediation addresses a known finding. A penetration test investigates exploitable weaknesses and attack paths across a broader defined scope. If you need to discover what else is vulnerable, choose a broader assessment.
How is remediation validation different from rerunning a scanner?
A scanner retest asks whether the tool still detects a condition. Independent validation uses human-led testing to evaluate the remediation, relevant bypasses, and supporting evidence. Both approaches can be useful, but they answer different questions.
Can we use CyberCile's validation evidence with a customer or bank?
You can share appropriate evidence subject to confidentiality and the requesting party’s requirements. Confirm which scope, dates, outcomes, and artifacts they need. Validation does not guarantee compliance, acceptance, or approval by a bank, customer, auditor, or regulator.
Can MSPs submit findings on behalf of clients?
Yes, with appropriate client authorization and agreement on scope, access, testing restrictions, and evidence handling. The partner manages the client relationship and remediation process while CyberCile independently evaluates eligible fixes and returns documented results.
How long does validation take?
Timing depends on the finding, reproduction complexity, access readiness, testing restrictions, dependencies, and volume. CyberCile confirms feasibility and scheduling during scoping. Selecting a target deadline in the intake is a request, not a guaranteed turnaround.
How much does remediation validation cost?
Pricing depends on finding type, complexity, access requirements, validation effort, volume, and engagement model. Submit non-sensitive qualification details to request a validation scope. Pricing is confirmed after eligibility and the required work are understood.
The finding says fixed. Let's find out if it holds.
Send CyberCile the original finding and remediation context. We'll determine whether it is eligible for independent validation and what is required to test it defensibly.
Start with the short qualification form. Do not send technical findings or credentials here; secure exchange follows qualification.
Need broader testing? Explore Penetration Testing →