Information Security
Scrut Automation
Provenance unknown Report an error0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by Scrut Automation Pvt. Ltd. · scrut.io
Report an error on this page Is this your product? →
Link to this page
Add ?theme=dark to the image address for dark backgrounds.
The badge shows the category and the month of the latest evaluation, and EU-Made where
that is the product’s provenance. It never shows a score.
Scrut Automation at a glance
- Vendor
- Scrut Automation Pvt. Ltd.
- Headquarters
- Not stated on the vendor’s pages as of 13 Oct 2026
- Data hosting
- Not stated on the vendor’s pages as of 13 Oct 2026
- Free plan
- Not stated on the vendor’s pages as of 13 Oct 2026
- Panel verdict
- The AI panel rates Scrut Automation 3/5, the mean of 6 judges. Scrut Automation is a security-compliance platform whose strongest showing is framework coverage at 8-9: 70-plus out-of-the-box frameworks, including NIS 2, DORA and TISAX V5.1, mapped through a Unified Control Framework onto a single control set. how scores are made
- As of
- Vendor pages captured 13 Oct 2026; evaluated by the panel 15 Oct 2026. all sources
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
Scrut Automation is a security-compliance platform whose strongest showing is framework coverage at 8-9: 70-plus out-of-the-box frameworks, including NIS 2, DORA and TISAX V5.1, mapped through a Unified Control Framework onto a single control set. Controls and statement-of-applicability work follows at 6-7 — the SoA is generated per ISO framework with justification and policy references auto-populated at export — and audit readiness sits at 7 on a per-requirement zip export with linked evidence, findings and corrective actions. The weak spots are sharp: information security management clusters at 4, since automated asset discovery from cloud, MDM and code repositories is real but we found no public information on risk methodology, treatment tracking or incident handling; sovereignty sits at 0-1, where the captured terms name Riversys under Indian law and Scrut Automation Inc. under Delaware law, with arbitration in New Delhi or San Francisco, and no public information on hosting locations, a DPA or a subprocessor list. The judges show no genuine split — no criterion spans more than one point. We found no public prices for the Foundation, Growth and Scale tiers.
Speaks for it
- Framework coverage scores 8-9, with 70+ frameworks out of the box mapped through a Unified Control Framework onto one control set
- The Statement of Applicability is generated per ISO framework with policy references auto-populated at export and a version-control tab carrying revision history
- The Audit Package exports a per-requirement zip of linked policies, evidence, tests, findings, requests and corrective actions for offline review
- Automated asset discovery syncs cloud platforms, MDM tools and code repositories with owner and criticality metadata
- A documented API exchanges client credentials for short-lived tokens with credential audit logging, available on Foundation, Growth and Scale plans
Held against it
- Information security management scores cluster at 4, and we found no public information on risk methodology, treatment tracking, risk acceptance or incident handling
- Sovereignty scores sit at 0-1, with the captured terms naming Riversys under Indian law and Scrut Automation Inc. under Delaware law and arbitration seated in New Delhi or San Francisco
- We found no public information on hosting locations, data residency, a data processing agreement or a subprocessor list
- We found no public information on control-measure ownership, due dates, delegation or escalation
- We found no public information on ticketing or CMDB connectors, webhooks, or SSO and SCIM provisioning
Best for
- You run ISO 27001 alongside NIS 2, DORA or TISAX and want many frameworks answered from one control set with reusable evidence
- You prepare ISO certifications in-house and want a generated Statement of Applicability with auto-populated policy references rather than a consultant's spreadsheet
- You maintain your asset inventory by hand and want automated discovery from cloud platforms, MDM tools and code repositories with owner and criticality metadata
- You want to script evidence uploads and vulnerability findings against an API available on the Foundation, Growth and Scale plans
Avoid if
- You need a documented risk methodology, treatment tracking, risk acceptance with ownership and incident workflows with statutory reporting clocks before you sign — this is where the bench scored lowest on product depth
- You must contract with a European entity or under European law; the captured terms name Indian and Delaware contracting paths with arbitration in New Delhi or San Francisco
- You need to reconstruct the ISMS state on a past date or hand auditors dedicated access roles, which the captured pages do not document
- Your toolchain depends on ticketing or CMDB connectors, webhooks or SSO and SCIM provisioning beyond the documented cloud, MDM and code-repository feeds
The scores
| Criterion | Panel median |
|---|---|
| Asset & risk management depth | 2 of 5 |
| Controls, SoA & measures | 3.5 of 5 |
| Framework & standard coverage | 4 of 5 |
| Audit readiness & evidence | 3.5 of 5 |
| Integrations & automation | 3 of 5 |
| European sovereignty | 0.5 of 5 |
Asset & risk management depth
Show reasoningHide reasoning
How this is scored
The ISMS core: asset inventory, risk methodology (identification, assessment, treatment), protection-needs inheritance, incident handling with statutory clocks.
0 — No ISMS substance; "information security" is a chapter in the marketing site.
3 — A flat risk list and an asset spreadsheet import; no treatment tracking, no inheritance, incidents live in the ticket system.
5 — Asset and risk management with configurable matrices and treatment tracking; basic incident handling; inheritance and aggregation need manual work.
8 — A real risk backbone: documented methodology (ISO 27005 or equivalent), inherited protection needs across asset relations, incident workflows with statutory reporting clocks (NIS2 24h/72h), risk acceptance with ownership.
10 — Risk management a certifier works inside: complete asset-risk-treatment chain with inheritance, continuity planning, incident reporting with authority export, and risk reporting the executive level actually reads.
The CISO
Automated asset discovery from cloud, MDM and repositories with owner assignment, criticality labels and risks created straight from an asset is more than a spreadsheet, and controls link to risks in the register. But I found no public information on a documented risk methodology, treatment tracking with acceptance and named ownership, or any incident workflow — let alone statutory reporting clocks — and that backbone is what I buy for. Sits between a flat risk list and a working backbone, carried by the asset side. 3 4
The GRC Consultant
Automated discovery of cloud, device and code-repository assets with owner, region and criticality metadata, plus risks creatable straight from an asset and linked to controls, sits above a flat spreadsheet import. The risk methodology side is where it stops: we found no public information on assessment matrices, treatment tracking, risk acceptance with ownership, protection-needs inheritance, or incident handling with statutory reporting clocks. 3 4
The Drafted IT Officer
Automated discovery that syncs cloud assets, devices and code repositories into one register, with owners, departments and criticality labels, is exactly the part of an ISMS I can keep alive next to my day job. But the risk side is only ever shown as linking — controls attach to risks, risks attach to assets — and we found no public information on a risk methodology, treatment tracking, or any incident handling, let alone statutory reporting clocks. Strong inventory, a risk process we cannot see. 3 4
The Lead Auditor
The asset side is real — automated discovery from cloud platforms, MDM and code repositories, owner and criticality metadata, and risks created directly from an asset that sync into the register. But I found no public information on a documented risk methodology, treatment tracking, risk acceptance with ownership, protection-needs inheritance, or any incident handling with statutory reporting clocks, and for the ISMS core that silence decides the bench. 3 4
The Evidence Integrator
Live asset discovery from cloud platforms, MDM and code repositories feeding a risk register, with owners pulled from a central employee directory and risks creatable directly off any asset, is the right shape for a real ISMS. We found no public information on a documented risk methodology, treatment tracking, risk acceptance with ownership, protection-needs inheritance across asset relations, or incident handling with statutory reporting clocks, which is what holds this below the middle of the scale. 3 4
The Skeptic
Automated asset discovery from cloud platforms, MDM tools and code repositories, with owners, regions and criticality metadata, asset-to-risk linking, and a risk register that syncs asset-linked risks is genuinely more than a spreadsheet import. But I found no public information on a documented risk methodology, treatment tracking, risk acceptance with ownership, protection-needs inheritance, or incident workflows with statutory reporting clocks — the core ISMS machinery is evidenced only at its edges. 3 4
Controls, SoA & measures
Show reasoningHide reasoning
How this is scored
Control catalogs, statement of applicability, measure tracking and internal audit — whether the control side of the ISMS is operable or a checklist.
0 — A static control checklist; applicability, implementation status and evidence are the consultant's spreadsheet.
3 — Control catalogs with status fields, but no SoA generation, no measure ownership, no link between controls and risks.
5 — Controls linked to risks and measures with owners and due dates; SoA producible with manual assembly; internal audit supported by checklists.
8 — SoA on demand from live control status, measure tracking with delegation and escalation, internal audit workflows with findings management, controls carrying their own evidence.
10 — The control fabric as a living system: catalog updates versioned, SoA always current, audit programs with recurring schedules, and every control answerable with linked evidence at any moment.
The CISO
The Statement of Applicability generator is the strongest thing here: applicability with justification categories, implementation details preserved through scope changes, document references auto-populated from linked policies, and a version-control tab with owner, approver and revision history. Internal audit carries findings, requests and corrective actions, and controls link to risks and carry their own evidence folders. I found no public information on measure tracking with delegation and escalation, which is what keeps a control program from coasting. 3 5 6 9
The GRC Consultant
The Statement of Applicability is generated on demand from live control status, with justification, implementation details and linked policy references populated from the system itself, and the audit side runs findings, requests and corrective actions per requirement. What keeps it short of the top is the measures layer: we found no public information on control or measure ownership, due dates, delegation or escalation — the only owner and approver fields evidenced sit on the SoA document itself. 3 5 6 9
The Drafted IT Officer
The Statement of Applicability is generated on demand from live control data, with implementation details pre-filled from the framework module and policy references auto-populated at export, plus a version-control tab carrying owner, approver and revision history — that saves me a week of spreadsheet surgery. Audits come with findings, requests and corrective-action folders. We found no public information on measure tracking with owners, due dates, delegation or escalation, which is the difference between a checklist I babysit and a system that chases people for me. 3 5 6 9
The Lead Auditor
The Statement of Applicability is a generated artifact rather than a consultant's spreadsheet: per-control applicability and justification, implementation details, policy references auto-populated at export, and a Document Version Control tab with revision history. Controls link to risks, map across frameworks through the unified control repository, and audits carry findings, requests and corrective actions. I found no public information on measure ownership with delegation and escalation, or on versioned catalog updates, which keeps this off the top bench. 3 5 6 9 10
The Evidence Integrator
The Statement of Applicability is generated on demand with implementation details pulled from live control data, policy references auto-populated at export, and a document version control tab carrying owner, approver and revision history — and audits hold findings, requests and corrective actions. Risks link to controls and the Unified Controls Framework maps many regimes onto one control set. We found no public information on measure-level owners and due dates, delegation, or escalation, so the measure-tracking side is thinner than the SoA machinery. 3 5 6 9
The Skeptic
The SoA generator is the real thing: per ISO framework, with applicability, justification categories, implementation details that survive scope changes, document references auto-populated from linked policies at export, and a version-control tab with revision history. Findings, requests and corrective actions exist as first-class audit objects and controls link to risks; what I found no public information on is measure ownership, delegation and escalation. 3 5 6 9
Framework & standard coverage
Show reasoningHide reasoning
How this is scored
Which regimes the product actually operationalizes — ISO 27001, NIS2, TISAX/VDA ISA, DORA, BSI IT-Grundschutz, SOC 2 — and whether one control maps across them or each framework is a fresh island.
0 — One framework, hard-coded; anything else is "on the roadmap".
3 — Two or three frameworks as separate checklists; the same control is answered once per framework.
5 — The major regimes for its market with partial cross-mapping; newer regimes (NIS2, DORA) present as content packs of varying depth.
8 — Broad current coverage including NIS2/TISAX/DORA where relevant, one-control-many-frameworks mapping, and visible maintenance as regimes evolve.
10 — Framework coverage as a living product: dozens of regimes, genuine multi-compliance mapping on one data basis, per-industry profiles, and documented update cadence when the standard moves.
The CISO
Seventy-plus frameworks out of the box including NIS 2, DORA and TISAX, mapped through a unified control framework with 1500+ overlapping controls and evidence reused across regimes — one data basis answering many regimes, exactly what a 27001-plus-NIS2 shop needs. Custom frameworks with entity linking and a premapped control library sit on top. I found no public information on a documented update cadence when a standard moves. 4 6 7 8
The GRC Consultant
Seventy-plus frameworks including NIS2, DORA and TISAX V5.1, with a Unified Controls Framework mapping requirements from many standards onto a single control set and evidence reusable across regimes — the one-control-many-frameworks pattern I build client ISMSs around, plus custom framework creation. Version currency (ISO 27701:2025, PCI DSS 4.0, NIST CSF 2.0) shows real maintenance; we found no public information on a documented update cadence or per-industry profiles. 4 6 7 8
The Drafted IT Officer
Seventy-plus out-of-the-box frameworks including ISO 27001, SOC 2, NIS 2, TISAX and DORA, mapped onto a proprietary unified control set so one answer serves many frameworks, with collected evidence reusable across them — that is the multi-compliance workhorse a one-person security function actually needs. Custom frameworks are available on the upper tiers. We found no public information on a documented update cadence when a standard moves, so I am trusting the phrase 'growing library' rather than a maintenance promise. 4 6 7 8
The Lead Auditor
Seventy-plus frameworks out of the box at current versions — ISO 27001:2022, NIST CSF 2.0, TISAX V5.1, PCI DSS 4.0, with NIS 2 and DORA present — mapped one-control-many-frameworks through the Unified Control Framework, with reusable evidence and custom framework creation on a premapped control library. I found no public information on a documented update cadence when a standard moves, which is what separates a living product from a broad catalog. 4 6 7 8
The Evidence Integrator
Seventy-plus frameworks out of the box, including current regimes like the NIS 2 Directive, TISAX V5.1, DORA and ISO 27701:2025, mapped through a Unified Control Framework claiming 1500+ overlapping controls onto a single control set, plus custom framework building and a growing ready-made library. We found no public information on per-industry profiles or a documented update cadence when standards move, which is the distance to the top of the scale. 4 7 8
The Skeptic
70-plus frameworks out of the box with current-version listings — TISAX V5.1, PCI DSS V4.0, NIS2, DORA — mapped through a Unified Controls Framework onto one control set, plus custom framework building on higher plans. I found no public information on a documented update cadence or per-industry profiles, and the 1500+ overlapping-controls count appears only as a platform-page figure whose depth I cannot check from the captured pages. 4 6 7 8
Audit readiness & evidence
Show reasoningHide reasoning
How this is scored
Whether the system produces defensible proof: revision-safe history, evidence collection, reports for auditors, authorities and management.
0 — Exports are screenshots; history is overwritten in place.
3 — PDF reports exist but evidence is attached ad hoc and changes leave no reliable trail.
5 — Versioned records, standard report generators, evidence attachments per control; assembling a full audit file still takes days.
8 — Revision-safe change history, audit-scoped evidence packs on demand, management reports current at a click, auditor access roles.
10 — Audit readiness as a standing state: continuous evidence status per framework and scope, exportable proof packs an external auditor accepts as-is, and a defensible answer to "show me the state on date X".
The CISO
The audit package assembles a requirement-by-requirement offline export with linked policies, evidence, tests, findings and corrective actions, and the readiness report ships structured data an auditor can verify independently — a real audit file, not screenshots. Evidence uploads are logged with the acting credential named, and the SoA carries revision history. I found no public information on revision-safe change history across the whole platform, auditor access roles, or a defensible answer to the state on a given date. 5 9 10 11
The GRC Consultant
The offline audit package is a genuine proof pack — a zip organized by requirement carrying policies, evidence, tests, findings, requests and corrective actions, and the readiness report ships structured data so an auditor can verify independently. We found no public information on revision-safe history for records generally (audit logging is evidenced only for API credential actions and evidence uploads), on auditor access roles, or on reconstructing the state as of a past date. 9 10 11
The Drafted IT Officer
The offline audit package is a genuinely defensible export: one zip organized per requirement, with policy, evidence, test, findings, requests and corrective-action folders an auditor can review without an account, and the summary readiness report includes structured data so their tooling can verify it. The developer console also logs every credential action with the actor named. We found no public information on revision-safe history across the wider records, auditor access roles, or reconstructing the state on a given date, so 'show me what it looked like in March' stays an open question. 9 10 11
The Lead Auditor
The Audit Package is a genuine evidence pack on demand — one folder per requirement with linked policies, evidence, tests, findings, requests and corrective actions, exported with a framework-and-date filename — and the readiness report includes structured data an auditor can independently verify. But I found no public information on revision-safe change history across records generally, auditor access roles, or a defensible answer to 'show me the state on date X', and that answer is the one I certify against. 5 9 10 11
The Evidence Integrator
The Audit Package export produces a complete, requirement-by-requirement offline copy with linked policies, evidence, tests, findings, requests and corrective actions, and the readiness report ships structured data an auditor can run their own tooling over — evidence packs on demand, not a days-long assembly. API actions and evidence uploads land in audit logs with the credential as actor. We found no public information on revision-safe change history for ISMS records, dedicated auditor access roles, or a point-in-time reconstruction of the state on a given date. 9 10 11
The Skeptic
The Audit Package is a defensible evidence pack: a zip organized per requirement with linked policies, evidence, tests, findings, requests and corrective actions, downloadable at any point in the audit lifecycle, and the readiness report ships structured data so auditors can verify independently. Change history is only evidenced as developer-console audit logs of API actions, and I found no public information on auditor access roles or reconstructing the state on a past date. 9 10 11
Integrations & automation
Show reasoningHide reasoning
How this is scored
Whether the platform feeds from the real IT estate — directory import, CMDB, ticketing, scanners, API — and automates evidence collection instead of re-typing it.
0 — A closed island: manual entry in, PDF out, no API.
3 — CSV/Excel import and export; no live connections, no API worth the name.
5 — Directory import (AD/Entra), a documented REST API for core objects, a handful of native connectors (ticketing, CMDB or SSO); automation is reminders and recurrence.
8 — Real connector set (Jira/ServiceNow-class ticketing, CMDB, cloud and endpoint sources), webhooks, SSO/SCIM, automated evidence tests with human review.
10 — The platform behaves like infrastructure: API parity for the data model, event streams, continuous control monitoring against the live estate, and automation that measurably removes the recurring toil rather than renaming it.
The CISO
A documented API with scoped client credentials that can upload evidence and write vulnerability findings on every plan, plus automated asset discovery from cloud, MDM and repositories and continuous automated tests across the stack, is real feeding from the estate rather than re-typing. But the connector set is described by category, not by name: I found no public information on ticketing or CMDB connectors of the Jira or ServiceNow class, webhooks, or SSO and SCIM provisioning. 4 7 11
The GRC Consultant
A documented API with scoped credentials, expiry and revocation covers reads across all modules plus evidence upload and vulnerability findings, and asset discovery runs from cloud platforms, MDM tools and code repositories with continuous automated tests across the stack. The connector story stops there: we found no public information on ticketing or CMDB connectors, webhooks, SSO or SCIM, or write parity for the wider data model. 4 7 11
The Drafted IT Officer
A real API with scoped, expiring credentials available on every plan, automated asset sync from cloud platforms, MDM tools and code repositories, and continuous automated tests across the stack mean I am not re-typing my estate into a form. However, we found no public information on ticketing connectors, webhooks or SSO/SCIM provisioning, and the connector story beyond cloud, MDM and code repositories is undocumented, so the 'feeds from the real IT estate' claim is only half evidenced. 4 7 11
The Lead Auditor
There is a documented API with scoped credentials, short-lived tokens, audit-logged actions and write paths for evidence upload and vulnerability findings, plus automated asset discovery from cloud, MDM and repository sources and automated evidence collection reusable across frameworks. I found no public information on ticketing or CMDB connectors of the Jira/ServiceNow class, on SSO or SCIM provisioning, or on webhooks, so the estate feed is real but not yet infrastructure-grade. 4 7 11 12
The Evidence Integrator
Continuous automated tests across the tech stack, automated evidence collection reused across frameworks, and assets syncing live from cloud platforms, MDM and code repositories is precisely the anti-island posture I look for. The API is real — token-authenticated credentials with read and read/write scope across all modules and entities, available on every plan, with full audit logging — but we found no public information on ticketing or CMDB connectors, webhooks, SSO/SCIM, or full parity between the API surface and the UI. 4 7 11
The Skeptic
A documented API with client credentials exchanged for short-lived tokens, scoped read/write covering evidence upload and vulnerability findings with credential audit logging, plus live asset sync from cloud, MDM and code repositories and continuous automated compliance tests across the tech stack. I found no public information on webhooks, SSO/SCIM, or ticketing and CMDB connectors of the Jira/ServiceNow class. 4 7 11
European sovereignty
panel opinion
Show reasoningHide reasoning
How this is scored
Where the security posture of the whole company actually lives and under whose law — entity, hosting, subprocessors, DPA. The risk register is itself a target.
0 — Non-EU entity, non-EU-default hosting, no public DPA or subprocessor list — for the system holding your risk register.
3 — A DPA exists and an EU region is available on request or on top tiers; subprocessor exposure to US CLOUD Act reach is broad or undocumented.
5 — EU hosting is the default, DPA and subprocessor list published; the vendor or a critical subprocessor is still within non-European jurisdictional reach.
8 — EU entity, EU hosting with named data centers, published subprocessor list free of content-touching non-EU processors, DPA and TOMs public.
10 — Jurisdictionally clean end to end: European ownership, EU-only hosting and subprocessors, on-premises or sovereign-cloud options, and the whole chain documented publicly.
The CISO
The captured terms put the contracting parties under Indian law seated in New Delhi and Delaware law arbitrated in San Francisco, with support hours in IST or EST — my risk register would live outside any European jurisdiction. I found no public information on hosting location, a data processing agreement, or a subprocessor list, and the only security commitment quoted is commercially reasonable industry standard measures. For the system holding the register itself, that is a hard stop. 2
The GRC Consultant
The terms place contracting parties under Indian or Delaware law with arbitration seats in New Delhi and San Francisco — neither European — and the only security commitment is 'commercially reasonable industry standard measures'. We found no public information on hosting location or an EU region, a DPA, or a subprocessor list, so the jurisdiction of the system that would hold my clients' risk registers is essentially undocumented. 2
The Drafted IT Officer
For the system that would hold my entire risk register, the captured terms place the contracting parties under Indian and Delaware law, and we found no public information on data residency, hosting locations, a subprocessor list, a data processing agreement or TOMs. The offboarding terms are at least concrete — thirty days of restricted access for retrieval, then deletion after a year in cross-region backup. As the person who would have to sign for this, that combination is the dealbreaker. 2
The Lead Auditor
The captured terms name two contracting paths — an Indian entity under Indian law and a US entity under Delaware law — with support hours quoted in IST and EST, and the security commitment is limited to 'commercially reasonable industry standard measures'. I found no public information on EU hosting, named data centers, a data processing agreement or a subprocessor list; for the system that would hold your risk register, nothing in the captured pages places it under European jurisdiction. 2
The Evidence Integrator
The captured terms name Riversys under Indian law and Scrut Automation Inc. under Delaware law as the contracting parties, and we found no public information on data residency, EU hosting options, a published DPA or TOMs, or a subprocessor list — thin footing for the system holding the risk register itself. Offboarded customer data sits for a year in a cross-region backup "managed by the cloud" with the provider unnamed. 2
The Skeptic
The captured terms name Indian and Delaware contracting entities with arbitration seated in New Delhi or San Francisco, and commit only to "commercially reasonable industry standard" measures. I found no public information on EU hosting, a public DPA, or a subprocessor list for the system that would hold your risk register. 2
Pricing transparency
not rated — the vendor publishes no price
Show reasoningHide reasoning
How this is scored
Whether a buyer can compute the real invoice — per module, per entity, per year, with consulting unbundled — from public pages alone. Unpublished pricing is the B2B norm in this market, so this criterion describes rather than condemns; the benches weight it accordingly.
0 — No public prices at all; every configuration is a sales conversation.
3 — An entry price exists, but module add-ons, scale steps or bundled consulting make the real total incomputable.
5 — Most editions carry real numbers with billing period stated and software separated from services; at least one commonly needed module or scale step is unpriced.
8 — Every edition and module priced publicly with entity/user boundaries and setup fees stated; only genuine corporate-group contracts are custom.
10 — Complete price computability: modules, scale steps, service packages and renewal rules public, so the invoice for a 100-employee company and a certification project is a two-minute exercise.
The CISO
The captured pages name Foundation, Growth and Scale tiers and show feature gating — custom frameworks start at Growth — but I found no public information on prices, billing periods or setup fees. The invoice is a sales conversation, not a computation, and every configuration has to be asked for. 6 8
The GRC Consultant
Three tiers — Foundation, Growth and Scale — are named publicly and the feature gates are visible (custom frameworks sit on Growth and Scale), but not a single figure appears anywhere we captured: we found no public prices for any edition, module, or consulting service. A buyer cannot compute any invoice from these pages; every configuration is a sales conversation. 5 8
The Drafted IT Officer
We found no public prices at all: the captured pages name the Foundation, Growth and Scale tiers and document which features sit in which, but we found no public information on figures, billing periods, setup fees or service bundles. The terms do spell out auto-renewal with thirty days' written non-renewal notice, so the renewal mechanics are readable even though the invoice itself is a sales conversation. 2 5
The Lead Auditor
Three plan tiers — Foundation, Growth and Scale — are named throughout the help documentation as feature gates, but I found no public price figures for any plan, module, or service package in the captured pages. A buyer cannot begin to compute the invoice from public information, and consulting-type services are likewise unpriced. 5 11
The Evidence Integrator
Plan names — Foundation, Growth and Scale — gate features throughout the documentation, but no public price figures, billing periods, user or entity boundaries, or setup fees appear in the captured pages. Every real total starts as a sales conversation. 5 8
The Skeptic
Plan names — Foundation, Growth, Scale — recur across the help pages and gate features such as custom frameworks, but I found no public information on what any plan costs. Every real invoice therefore starts as a sales conversation, with auto-renewal on Order Form terms unless cancelled 30 days out. 2 5 8 11
European sovereignty — proven facts
0 of 4 dimensions provenBuilt only from facts shown on the vendor's own pages. A dimension we could not prove is left open, not scored as zero.
| Legal entity | Not determined ⚠ unverified | — | uncited Report an error |
|---|---|---|---|
| Ownership | Not determined | — | uncited Report an error |
| Data residency | Not determined | — | uncited Report an error |
| Subprocessors | Not determined | — | uncited Report an error |
Questions about Scrut Automation
Is Scrut Automation European?
Not determined: the vendor’s pages as captured do not say where Scrut Automation is based.
Where does Scrut Automation store data?
Not stated on the vendor’s pages as of 13 Oct 2026.
Does Scrut Automation have a free plan?
Not stated on the vendor’s pages as of 13 Oct 2026.
What are the best alternatives to Scrut Automation?
As of 21 Oct 2026, the panel rates 6clicks (3.5/5), preeco | informationssicherheit (3.5/5) and Secfix (3.5/5) highest among the other 26 Information Security products evaluated. Ratings that look equal are rounded to half stars; the order uses the unrounded rating, then the name. The highest-rated European alternative is preeco | informationssicherheit (EU-Made). Ratings are the AI panel’s opinion, formed from public evidence: how scores are made. The full list, with European products first: Scrut Automation alternatives.
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 13 Oct 2026. Vendors change pricing and policies without notice; every fact reflects its source as of the capture date shown in the registry.
- Weak sourcing — Legal entity. Not confirmed on the vendor’s own pages as captured.
- AI can misread a source. Extraction and judgement are automated; a citation guarantees traceability, not infallibility. If something here is wrong, say so — no account needed, every report is decided within 5 business days, and accepted corrections are published.
What we left out
A claim that does not survive our checks costs us the claim, not the page. This is what was taken off this one.
- 60 product facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 4 integrations facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 3 support facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 1 compliance fact could not be confirmed on the vendor’s page as captured and was left out of this page and of the panel’s material. Know more? Tell us
- 1 legal fact could not be confirmed on the vendor’s page as captured and was left out of this page and of the panel’s material. Know more? Tell us
- 1 sovereignty dimension could not be confirmed on the vendor’s own pages and is shown as unknown. Know more? Tell us
- 6 of the readings below were written against an earlier fact sheet — a fact has been corrected, added or pulled since. Until the panel next runs on this product you are reading the older judgement. Know more? Tell us
Sources (12)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Vendor page scrut.io Checked 13 Oct 2026 Details →
- 2 Terms of service — found from the homepage www.scrut.io Checked 13 Oct 2026 Details →
- 3 Asset & risk management depth — found from sitemap help.scrut.io Checked 13 Oct 2026 Details →
- 4 Asset & risk management depth — found from sitemap www.scrut.io Checked 13 Oct 2026 Details →
- 5 Controls, SoA & measures — found from sitemap help.scrut.io Checked 13 Oct 2026 Details →
- 6 Controls, SoA & measures — found from sitemap help.scrut.io Checked 13 Oct 2026 Details →
- 7 Framework & standard coverage — found from sitemap www.scrut.io Checked 13 Oct 2026 Details →
- 8 Framework & standard coverage — found from sitemap help.scrut.io Checked 13 Oct 2026 Details →
- 9 Audit readiness & evidence — found from sitemap help.scrut.io Checked 13 Oct 2026 Details →
- 10 Audit readiness & evidence — found from sitemap help.scrut.io Checked 13 Oct 2026 Details →
- 11 Integrations & automation — found from sitemap developer.scrut.io Checked 13 Oct 2026 Details →
- 12 Integrations & automation — found from sitemap www.scrut.io Checked 13 Oct 2026 Details →