Every finding has a deadline. Meet it with proof.
Robochicken doesn’t make you compliant. It makes the remediation part fast and provable.
The audit fails on the finding nobody had time to fix
You probably bought your scanner to pass an audit. It does its part: it finds things, and it finds them early.
Then each finding starts a clock. Your policy says critical issues get fixed in 30 days and high issues in 60, and your auditor will sample findings to check you kept your word. A finding that’s still open on day 61 is an exception in your report.
Robochicken moves the work from writing the fix to reviewing it. And because every fix is a pull request with the evidence attached, there’s nothing to reconstruct when the auditor asks.
The clock starts when your scanner finds it, not when someone gets around to it
Pick your framework to see where the evidence lands
ISO/IEC 27001:2022 ISO 27001 wants “appropriate measures.” Ship them with evidence.
Your auditor samples findings and follows each one to closure
ISO 27001 doesn’t set a remediation deadline. Your own vulnerability management procedure does, and the auditor checks you followed it.
In practice that means they pick findings from your scanner and ask what happened next. Who evaluated it? What was done? When? How do you know it worked? The finding that never got a ticket, or got one that’s still open, becomes a nonconformity.
Robochicken answers all four questions in one artifact: a pull request with the finding ID, the change, the test run, and the re-scan, each with a timestamp.
What still belongs to you
- Your statement of applicability, risk assessment, and vulnerability management procedure. Robochicken works inside them.
- The remediation deadlines themselves. Set them in your procedure and Robochicken helps you meet them.
- The decision to merge. A person on your team approves every change.
Where Robochicken evidence maps to the standard
-
Annex A 8.8
Management of technical vulnerabilities
- What it asks
- Obtain information about technical vulnerabilities, evaluate your exposure, and take appropriate measures.
- What Robochicken contributes
- Your scanner provides the information and the exposure. Robochicken takes the measure and records it against the finding.
-
Annex A 8.9
Configuration management
- What it asks
- Establish, document, implement, monitor, and review security configurations.
- What Robochicken contributes
- Header and cloud fixes are written into your proxy config and infrastructure code, so the documented configuration and the running one stay the same.
-
Annex A 8.28
Secure coding
- What it asks
- Apply secure coding principles to software development.
- What Robochicken contributes
- Each fix uses your codebase’s own safe primitives, and the pull request explains the principle behind it in plain language.
-
Annex A 8.32
Change management
- What it asks
- Subject changes to information processing facilities and systems to change management procedures.
- What Robochicken contributes
- Every fix is a pull request through your normal review and branch protection. Robochicken never merges its own work.
-
Clause 10.2
Nonconformity and corrective action
- What it asks
- Take action to correct a nonconformity and review the effectiveness of that action.
- What Robochicken contributes
- The re-scan after deploy is the effectiveness review, and its result is attached to the closed ticket.
ISO 27001 questions
Does ISO 27001 require a specific remediation deadline?
Does using Robochicken make a company ISO 27001 compliant?
Is Robochicken ISO 27001 certified?
SOC 2 A Type II audit checks your SLA every day of the window
The SLA in your policy is the one you get tested against
SOC 2 doesn’t pick your remediation deadlines. You do, in your vulnerability management policy. Most teams commit to 30 days for critical findings and 60 for high.
Then a Type II audit samples findings from across a three-to-twelve-month window and checks each one was fixed inside that deadline. Compliance automation platforms such as Drata and Vanta flag the overdue ones as you go, which is useful right up until you don’t have an engineer free to fix them.
Robochicken turns the deadline into a review queue. The fix shows up as a tested pull request, usually long before the clock matters, and the evidence travels with it.
What still belongs to you
- Your system description, policies, and the SLA numbers in them.
- Detection. Robochicken runs no scans and relies on the scanner you already use.
- The decision to merge. A person on your team approves every change.
Where Robochicken evidence maps to the criteria
-
CC7.1
Detection and monitoring of vulnerabilities
- What it asks
- Use detection and monitoring procedures to identify configuration changes that introduce vulnerabilities, and susceptibility to newly discovered ones.
- What Robochicken contributes
- Your scanner detects. Robochicken closes what it detects and asks it to confirm, so monitoring leads somewhere you can show.
-
CC4.2
Communicating deficiencies
- What it asks
- Evaluate and communicate deficiencies in a timely manner to the people responsible for corrective action.
- What Robochicken contributes
- Each finding becomes a pull request assigned to the owners of that code, with the business impact written for a non-specialist.
-
CC8.1
Change management
- What it asks
- Authorize, design, develop, test, approve, and implement changes to infrastructure and software.
- What Robochicken contributes
- Fixes are tested before review, approved by your engineers, and deployed through your pipeline, which is the trail CC8.1 sampling looks for.
-
CC3.2
Risk identification and analysis
- What it asks
- Identify and analyze risks to the achievement of objectives as a basis for managing them.
- What Robochicken contributes
- Every pull request carries the scanner’s severity, CVSS vector, and EPSS score, so the priority decision is recorded with the fix.
SOC 2 questions
What remediation SLA does SOC 2 require?
Which SOC 2 criteria does Robochicken produce evidence for?
Is Robochicken SOC 2 audited?
GDPR Article 32 asks you to test your security, and to act on what you find
An exploitable finding on a system holding personal data is a breach in waiting
GDPR is written in terms of risk, not checklists. Article 32 asks for security appropriate to the risk, and for a process that regularly tests whether your measures work.
Your scanner is the testing. What a regulator will want to see after an incident is what you did with the results, and when.
An unfixed access control flaw on a customer database is how a scanner finding becomes a breach notification under Article 33. Robochicken closes it in code and leaves a dated record that you did.
Questions to ask any remediation vendor, including us
- Source code is rarely personal data, but scanner traces, test fixtures, and logs can be. Ask what reaches the vendor, and add it to your record of processing if it does.
- Ask for the data processing agreement and the subprocessor list, including any AI model provider. For Robochicken, Worthwhile Adventures LLC provides both before a repository is connected.
- Ask where the test sandbox runs and how long anything in it lives. Robochicken destroys each sandbox when the run ends.
Where Robochicken evidence maps to the regulation
-
Article 32(1)(d)
Testing and evaluating effectiveness
- What it asks
- A process for regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures.
- What Robochicken contributes
- Scan, fix, and re-scan is that process, run continuously, with the result of each evaluation recorded.
-
Article 32(1)
Security of processing
- What it asks
- Technical measures that ensure a level of security appropriate to the risk.
- What Robochicken contributes
- Injection and access control fixes are the technical measures that keep personal data from being read by the wrong party.
-
Article 25
Data protection by design
- What it asks
- Measures built into processing that implement data protection principles effectively.
- What Robochicken contributes
- Tenant ownership checks and private-by-default storage are written into the code and infrastructure, not applied by hand.
-
Article 5(2)
Accountability
- What it asks
- Be able to demonstrate compliance with the principles of processing.
- What Robochicken contributes
- The pull request trail is the demonstration: what was found, what changed, who approved it, and proof it worked.
GDPR questions
What does GDPR Article 32 require for vulnerability management?
Does Robochicken process personal data?
Does using Robochicken make a company GDPR compliant?
Every fix carries its own audit trail
Your auditor wants to follow one finding from detection to closure. With Robochicken that’s one link.
Robochicken doesn’t hold certifications of its own. It was built inside Yembo’s ISO 27001, SOC 2 Type II, and GDPR program, to produce the evidence that program needed. You can check that program in Yembo’s trust center .
- The scanner’s finding ID, severity, CVSS vector, and EPSS score
- A cURL reproduction of the original exposure
- The diff, and the engineer who approved it
- The pre-flight test run against that exact commit
- The re-scan result confirming the exploit no longer works
- A timestamp on every step, from detection to closure
Audit window closing in? Put the backlog on a plan.
The Scale plan opens up to 60 tested pull requests a month against your open critical and high findings, and confirms each fix by re-running the attack that found it.
Get your audit evidence without the scramble
Tell me which frameworks you’re audited against and when your window opens, and I’ll tell you whether Robochicken can help before then.