--- title: "Security audit that retests | BionicAdri" description: "Every finding moves from suspicion to verified, fixed and closed with a new test, and a role matrix shows what each profile on your website sees." url: https://bionicadri.com/en/blog/auditoria-seguridad-retest-roles.html markdown: https://bionicadri.com/en/md/blog-auditoria-seguridad-retest-roles.md language: en updated: 2026-10-29 index: https://bionicadri.com/en/llms.txt publisher: "BIONICADRI SOLUTIONS S.L. · info@bionicadri.com · +34 604 87 17 35" translations: es: https://bionicadri.com/md/blog-auditoria-seguridad-retest-roles.md en: https://bionicadri.com/en/md/blog-auditoria-seguridad-retest-roles.md ro: https://bionicadri.com/ro/md/blog-auditoria-seguridad-retest-roles.md fr: https://bionicadri.com/fr/md/blog-auditoria-seguridad-retest-roles.md de: https://bionicadri.com/de/md/blog-auditoria-seguridad-retest-roles.md it: https://bionicadri.com/it/md/blog-auditoria-seguridad-retest-roles.md pt: https://bionicadri.com/pt/md/blog-auditoria-seguridad-retest-roles.md --- # A security audit that rechecks what's been fixed and who sees what A security report that says «there are 23 problems» and ends up in a drawer protects nothing. What protects you is knowing which ones were actually fixed, which are still there and which came back. ADRI keeps track of every finding and checks it again. By [Liviu Diaconu](https://bionicadri.com/en/nosotros.html#fundador) 29 Oct 2026 7 min read First of all: ADRI only audits **what's yours or what's authorised**. Before launching an active audit against a website, it asks you for an explicit yes in the chat with a declaration: that you own that target or that you have written authorisation from its owner. The request and your answer are recorded. By default, management, administration and the super-administrator can request audits, and every request, including denied ones, is kept on the scan audit screen. ## What is a vulnerability retest? It means testing a flaw again after someone says they've fixed it. It sounds obvious, but this is where things go wrong most often: the patch was applied on one server and not on another, one route was fixed and the one next to it is still the same, or a later update reopened it. With ADRI, a «re-test» is as simple as asking for another audit of the same target. The difference is that it now remembers what was decided about each finding. ## Each finding has its own record and its own status Each finding gets a stable identifier, of the type `H-1a2b3c4d`, which stays the same from one audit to the next. And it goes through these states: - **Suspected.** The scan found it and it isn't confirmed yet. - **Verified.** There's proof that it's real: ADRI records it with its note, or the scan itself proved it. - **Fixed.** A person says so, with the finding identifier in their message. ADRI can't mark it as fixed on its own. - **Closed.** In the next audit it no longer appears and the test that detected it ran properly. - **Reopened.** You marked it as fixed and it still shows up. There are also two decisions that only a person can make: **false positive** (it isn't a real problem) and **accepted** (it is real, but you take on the risk). Both are left with their note. ## When can a vulnerability be considered closed? Only when the new test proves it. The rules are strict on purpose: - If the test that was supposed to detect it **never ran or failed**, the re-test is marked as inconclusive, and it tells you so. Nothing gets closed just because nobody looked at it. - If an open finding simply doesn't appear, it doesn't close itself: it may be that this part wasn't checked that time. - If something that was closed appears again, it's marked as a **regression**, which is exactly what's most important to see. The summary of these changes goes at the top of the report: what was closed, what was reopened and what came back. ## What is a role-based access matrix? Many serious flaws can't be seen from the outside. An anonymous scan doesn't detect that an employee can open someone else's record, or that a portal customer sees invoices that aren't theirs. That's what the **role-based access matrix** is for. It works like this: you declare your application's roles in a file, with test accounts from your test environment, and which roles should be able to see each route. ADRI prepares the starting template for you if you give it the code. Then it requests each route with each role and compares: - 🔴 **Improper access:** a role that shouldn't be able to see the route, does. - ⚠️ **Unexpected block:** a role that should be able to see it, can't. - ❔ **Indeterminate:** a server error or an ambiguous response that has to be looked at by hand. To avoid causing damage, it only performs reads, doesn't follow redirects, doesn't leave the domain you gave it and has a cap on routes and roles, with pauses between requests. The report shows neither the page content nor the test cookies: only the status, the size and a fingerprint for comparison. You provide the test accounts; ADRI doesn't invent them or ask you for them over chat. ## If you have the code, the audit points to the line If you give it the path to your application's code, ADRI first builds a static map: which routes exist, which ones require a login and which ones reach sensitive operations. By cross-referencing it with the scan, a finding confirmed by code comes out with its cause: the file and the line. What the code hints at but the scan didn't touch stays as a lead, never as a finding. ## It diagnoses, it doesn't repair The audit points things out and prioritises them; it doesn't apply patches on its own. If something in the code needs fixing, ADRI prepares it and it's done with your approval. Then another audit closes the loop. More in [security and compliance](https://bionicadri.com/en/seguridad.html) and in [automated pentesting with AI agents](https://bionicadri.com/en/blog/seguridad-empresas-agentes-ia.html). If you're interested in how ADRI asks for permission before acting, we explain it in [when ADRI asks for your permission](https://bionicadri.com/en/blog/cuando-adri-pide-permiso.html), or [request a demo](https://bionicadri.com/en/contacto.html#formulario). ## Frequently asked questions **Can I audit another company's website?** Only if you own it or have written authorisation. Before an active audit, ADRI asks you for a yes with that declaration and it is recorded. **Who decides that a finding has been fixed?** A person, by typing in the finding's identifier. Then the next audit only closes it if the test ran and no longer finds it. **Can the role matrix change data in my application?** No. It only performs reads, doesn't follow redirects and doesn't leave the domain you gave it, with a cap on routes and pauses between requests. - Security - Audit - Roles - ADRI ## Related articles ### [Enterprise security with AI agents: automated pentesting](https://bionicadri.com/en/blog/seguridad-empresas-agentes-ia.html) ### [ADRI's Sentinel: what it watches on your servers, how it decides and what it leaves to a person](https://bionicadri.com/en/blog/centinela-seguridad-adri.html) ### [When ADRI asks for your permission and when it doesn't: a pause that protects without getting in the way](https://bionicadri.com/en/blog/cuando-adri-pide-permiso.html) ## See it with your company's data We show you ADRI working on a real task of yours, in about 15 minutes. [Request a demo](https://bionicadri.com/en/contacto.html#formulario) [info@bionicadri.com](mailto:info@bionicadri.com) · [+34 604 87 17 35](tel:+34604871735)