Will an auditor accept an automated security review?

As supporting evidence for specific controls, when the record is systematic and paired with human approval, yes. Auditors sample the record and follow one change end to end themselves. It is not an audit opinion, and it does not replace the accountable human.

How do we show the reviewer actually works?

The public planted-vulnerability runs at aevral.com/receipts are published with the misses included, the methodology is documented on the docs center, and your own record ties findings to the fix commits that answered them.

Who is accountable for the review?

The engineer who approves the merge. The agent is a first-line check that feeds the human review; a merge rule that accepts the agent's Check alone is the weakness an auditor will find. Name the human approval in your procedure.

Is Aevral itself covered by our ISMS?

Treat it as a supplier and expect supplier questions. aevral.com/security publishes what the App can do, what code is read, where it goes, and what is stored; the DPA, section 1.7, and the Aevral sub-processor page are binding. The company's ISO 27001 programme is public, and it is not certified today.

Does Aevral check ISO 27001 compliance on pull requests?

No. It reviews security on the diff. A reviewer that reads pull requests against ISO 27001 or SOC 2 controls is heyGRC, from the same company. What the Aevral trail gives you is the evidence for the secure-development controls described above.

What to show your ISO 27001 auditor.

Aevral is an AI security reviewer for GitHub pull requests. Every review it runs leaves a dated record on the pull request: a Check on the head commit, one summary review it edits in place as the pull request moves, and comments pinned to the changed lines. This page shows what that record contains, the secure-development controls it supports as evidence, and what to open when the auditor asks.

The question in the room

Sooner or later the auditor asks the question behind the secure-development controls: walk me through how a code change gets reviewed. Not the policy first. The record. Auditors sample: they pick a few merged pull requests from the audit window and follow one change end to end, from proposal to review to decision to approval.

If you use Aevral, that record already exists, on the pull request itself, dated and tied to exact commits. There is nothing to assemble the night before.

What Aevral checks for

PR review is live on install: installing the App starts PR reviews on the next pull request. Installing the App starts reviews, even before anyone signs in. Signing in to the console with GitHub later connects that install. Setup Complete can still turn them off. Reviews can be disabled at any time; reinstalling the App turns them back on. Paid PR plans are live in the console.

Every review looks for access control, business logic, SQL and command injection, XSS, SSRF, path traversal, unsafe deserialization, token and session flaws, and LLM-integration risks on the diff, and reads the most security-relevant changed files in full.
A finding is a lead, not a confirmation: it names the attacker, the missing control, the path from attacker to impact, why existing checks do not stop it, and a suggested fix, with a fix prompt you can hand to your coding agent. Aevral never applies or merges anything.
The bounds are stated on the record itself: at most five findings per review, severities from low to critical, inline comments on high and above, and a Coverage block that names every file read in part, excluded by rule, or withheld as sensitive.
Silence is recorded too. A clean pull request gets a Check that says so; a pull request that was not reviewed says why instead: docs-only change, model error with the retry, a cap pause, the cost safety limit, or PR too large to review.

Why an auditor cares

ISO 27001:2022 carries a block of secure-development controls in Annex A, A.8.25 to A.8.34. The audit question is never which tool you bought. It is whether a defined review step runs on every change, every time, and whether findings are handled. A timestamped trail of security reviews on your pull requests answers that question with the work itself.

What the record supports

A.8.25, secure development life cycle, and A.8.28, secure coding: a security review step runs on each supported pull request, from install, on its own, within the plan's allowance, and when a review does not run the Check on that pull request says why. The record shows review or reason, on every change.
A.8.29, security testing in development and acceptance, in part: an automated security review ran on each change, with coverage and results. The honest limit: it shows what this reviewer ran and flagged, not penetration testing or acceptance testing.
A.8.32, change management, in part: every reviewed change carries a Check and a review record with timestamps, posted before the human approval and the merge. The approval stays human.

What it does not cover

It does not cover A.8.26 (application security requirements), A.8.27 (secure system architecture and engineering principles), A.8.30 (outsourced development), A.8.31 (separation of development, test and production environments), or A.8.33 (test information). Those live upstream of the pull request, in design, procurement and infrastructure.
It does not show accountability. ISO 27001 expects a defined owner for review, and a bot check does not evidence who took responsibility. Keep a named engineer approving the merge: the agent feeds the review, the human owns it.
It is not a certification and not a compliance tool: the review reads security on the diff, and findings are leads for a human, not audit opinions. If what you need is a reviewer that checks pull requests against ISO 27001 or SOC 2 controls, that is heyGRC, from the same company.

Where the record lives on a pull request

All three records live on the pull request itself, in GitHub, dated and tied to exact commits. That matters for an audit: the evidence sits where the audited work happened, not in a vendor report.

The Check

Every review posts a Check named 'Aevral review' on the head commit of the pull request. The title states the outcome: 'No findings'; findings with their severities and a note that the review is advisory; 'Partial review: read X of Y code files' when coverage is incomplete; 'Docs-only change: not reviewed for code security'; 'Not reviewed: model error, push a new commit to retry'; the cost safety limit; or 'PR too large to review'. Leads the reviewer could not verify are listed in the Check under 'Unverified, worth a look' instead of becoming comments. A full, clean, verified run is the only success; every other outcome is neutral. The Check never reports failure, because the review never blocks the merge.

The running summary review

One comment headed 'Aevral security review' per pull request, edited in place at the end of every run: that is the running record. It carries the scope line, a note that open findings are listed as of the head commit, one block per open finding with the fields above, and a Coverage block naming every file read in part, not read, excluded by rule, or withheld as sensitive, so a partial review can never read as complete. On a public repository, a clean run posts the sentence: 'Reviewed by Aevral: no security findings in the reviewed changes, across Aevral's full code-security scope.' On a private repository, a clean run stays silent, and the Check is the record. A new review comment posts only when a push adds findings at medium severity or above, or grades an existing one higher; everything else updates in place. To have the whole pull request reviewed again, comment '@aevral review'.

Inline comments

Findings at high and critical severity post as comments pinned to the exact added lines, at most five per run, each ending in a 'Fix with your agent' block. That is the comment an auditor reads when they ask how a finding was handled: what was flagged, on which line, and what the suggested fix was.

Illustrative: the three records on one pull request. Wording paraphrases the product's review format.

Check on the head commit

Aevral review
1 finding (advisory)

Summary review, edited in place on every push

## Aevral security review
_Full code-security scope: authorization, business logic, injection, XSS, SSRF, path traversal, deserialization, crypto, authentication, LLM integration. Advisory; never blocks a merge._
_Open findings as of 3f9c2ab. Aevral edits this review on every push and posts a new review only for new findings._
### [high] Any logged-in user could open other customers' invoices  `src/invoices.ts:63`
Attacker: any signed-in user. Missing control: tenant filter on the invoice lookup.
Impact: one tenant reads another tenant's invoices.
Fix: scope the query to the caller's company before returning.
_Coverage: read in full: `src/invoices.ts`. Excluded by rule: `package-lock.json`._

Inline comment on the added line

Aevral: high | src/invoices.ts:63
The finding, its evidence, and a collapsed 'Fix with your agent' block.

On a clean pull request on a public repository, the summary review reads instead: 'Reviewed by Aevral: no security findings in the reviewed changes, across Aevral's full code-security scope.'

The walkthrough

01Pick two or three merged pull requests from the audit window. Include one that drew findings and one that came back clean.
02Open the 'Aevral review' Check on the head commit. The outcome title and its date are the receipt for that change.
03Open the summary review. The scope line, the open-findings note, and the Coverage block show the review was systematic, not spot-checking.
04Walk one finding end to end: the inline comment, the fix commit that answered it, and the human approval that merged it.
05Show the exceptions: findings that were accepted or dismissed, and where that decision is recorded (ticket, risk register, or the review thread itself).
06Open the console Reviews page (app.aevral.com/reviews): your most recent reviews, each linking out to its pull request.
07On Business and Scale plans, show the monthly export: a monthly export of the security reviews Aevral ran on your pull requests, with coverage and results, that may serve as supporting evidence for automated security testing in audits (for example ISO 27001 A.8.29, SOC 2 CC8.1). It is not an audit opinion and does not show who approved or fixed a change; the check runs and review comments carry the timestamps instead.
08Close with the policy side: the sentence in your secure-development procedure that makes the review mandatory. The trail is evidence that the process ran; the policy is the process.

One caveat to have an answer ready for: changes that bypassed the pull request path, like emergency hotfixes pushed directly. The pull-request record covers only what went through pull requests; an emergency-change procedure with a review after the fact is the usual answer. Say it before the auditor finds it.

Questions auditors ask

Will an auditor accept an automated security review?: As supporting evidence for specific controls, when the record is systematic and paired with human approval, yes. Auditors sample the record and follow one change end to end themselves. It is not an audit opinion, and it does not replace the accountable human.
How do we show the reviewer actually works?: The public planted-vulnerability runs at aevral.com/receipts are published with the misses included, the methodology is documented on the docs center, and your own record ties findings to the fix commits that answered them.
Who is accountable for the review?: The engineer who approves the merge. The agent is a first-line check that feeds the human review; a merge rule that accepts the agent's Check alone is the weakness an auditor will find. Name the human approval in your procedure.
Is Aevral itself covered by our ISMS?: Treat it as a supplier and expect supplier questions. aevral.com/security publishes what the App can do, what code is read, where it goes, and what is stored; the DPA, section 1.7, and the Aevral sub-processor page are binding. The company's ISO 27001 programme is public, and it is not certified today.
Does Aevral check ISO 27001 compliance on pull requests?: No. It reviews security on the diff. A reviewer that reads pull requests against ISO 27001 or SOC 2 controls is heyGRC, from the same company. What the Aevral trail gives you is the evidence for the secure-development controls described above.

Aevral is not a certification and not a compliance tool, findings are leads, and this page is not audit advice. Your auditor and certification body decide what evidence satisfies your controls.

The PR review product The security posture The ISO 27001 programme Public eval runs Docs: what a PR review looks like