Platform scan paths
Use when the buyer already knows the storefront or commerce platform.
WebRiskOps FAQ - Scans, reports, pricing, fixes, monitoring and limits
Answers for buyers, operators, agencies and reviewers who need to understand fit, authorization, scans, reports, pricing, fixes, monitoring, data handling, request routing and product boundaries before registration.
Use-case paths
Continue by platform, risk category or agency workflow
These links connect this resource page to focused product acquisition pages while keeping the main navigation short.
Risk category paths
Use when the buyer knows the risk area: consent, checkout, accessibility, security or trust.
Agency paths
Use when the buyer needs repeatable client scans, white-label reports or Agency Plan boundaries.
Next action
Route the question to the owning workflow
FAQ answers should point users to the public page, authenticated workflow or support route that owns the state instead of creating a manual detour.
Boundary
FAQ routing does not bypass product eligibility, authorization, billing state, evidence quality gates or legal boundaries.
- 01
Find the matching category
Start with fit, authorization, scanning, reports, pricing, fixes, data, limits or troubleshooting.
- 02
Open the owning page
Use pricing, reports, billing, support, authorization or data pages for the current state.
- 03
Continue with product context
Authenticated requests should include account, project, scan, report or billing context.
Fit and buyers
WebRiskOps is built for commercial sites and teams that need evidence-backed risk, conversion, accessibility and trust signals before launch or ongoing monitoring.
- Who is WebRiskOps for?
- Which sites are a poor fit?
- Can agencies use it?
Authorization, scans and reports
Customers authorize scope before scanner work starts; reports explain observed findings, evidence, severity and next actions.
- What can be scanned?
- What checks run?
- What does the report include?
Commercial and operational boundaries
Pricing, payments, credits, access modes, ticket-only fallback, retests, monitoring, data retention, legal boundaries and next-step routing stay explicit.
- How do payments and credits work?
- What access is required for fixes?
- Is this legal certification?
Categorized FAQ
Buyer, operator, agency, and reviewer questions
The FAQ covers the operational questions that usually block registration: fit, authorization, scans, reports, pricing, payments, credits, fixes, access modes, ticket-only fallback, retests, monitoring, agencies, data, security, legal boundaries, and support routing.
Fit and buyers
Use this section to decide whether the product is relevant before creating an account.
Who is WebRiskOps for?
WebRiskOps is for B2B teams, ecommerce operators, SaaS teams and agencies that need a technical risk scan of commercial journeys such as pricing, checkout, contact, signup, consent and trust pages.
Which sites are a poor fit?
Tiny blogs, hobby sites, sites without commercial flows, unsupported third-party properties and targets without clear ownership are poor fits for WebRiskOps.
Do you sell overlays or generic audits?
No. The product focuses on observed technical findings, evidence artifacts, remediation paths, retests and monitoring. It does not sell accessibility overlays or generic PDF-only audits.
Authorization and scope
Scope must be owned, controlled, or explicitly authorized before scanner work starts.
What can I scan?
You can scan owned or explicitly authorized websites and customer journeys that stay inside the accepted project scope. Unsupported or unsafe scope should be blocked before execution.
Can I scan a third-party website?
Only when you have explicit permission to test that target. The product is not intended for unsolicited probing of unrelated third-party sites.
What happens if scope is unsupported?
Unsupported scope stops the workflow before scanner work starts. The app should explain the reason, preserve an audit trail, and show either a revised-scope step or the support form.
Scanning and checks
Scanner output starts with repeatable technical evidence; AI-assisted wording is used only to help explain reviewed findings.
What checks run during a scan?
Checks can cover HTTPS and HSTS, security headers, console and network errors, mixed content, consent state, accessibility signals, forms, checkout paths, crawler coverage and unsupported scope signals.
How long does a scan take?
Runtime depends on crawl limits, pages selected, queue state and enabled modules. The customer app shows active, completed, failed, blocked and retryable states.
Do scans use private authenticated areas?
Private or authenticated paths require an accepted access mode. Without safe access, the scan should stay on public pages or use ticket-only remediation guidance.
Reports and evidence
Reports explain what was observed, why it matters, what evidence exists, and what should happen next.
What does a report include?
A report includes target, scope, risk score, executive summary, findings, severity, evidence artifacts, technical appendix, quality gates, next actions and interpretation boundaries.
Are screenshots and HTML snapshots always available?
Evidence availability depends on the check and scan result. The report should make availability explicit instead of pretending every finding has every artifact type.
Who can publish a public report link?
Public links should stay private until quality gates pass. Tokenized public URLs, print views, and PDFs must preserve disclaimers and avoid exposing private customer data.
Pricing, payments, and credits
Commercial flows use one subscription ladder: Free Snapshot, Scan Plan, Monitor Plan, Fix Plan and Agency Plan, with credits shown only after plan context is clear.
How is pricing structured?
Pricing is organized as one ladder: Free Snapshot, Scan Plan, Monitor Plan, Fix Plan and Agency Plan. Public pages compare outcomes; plan checkout continues after sign-in and project checks.
When are payments required?
Paid scans, monitoring and fix credits are checked inside the authenticated workflow before work starts. Public pages explain the model but do not collect payment directly.
How do fix workflow credits work?
Eligible findings can reserve fix credits before implementation, consume credits when work completes, fall back to tickets when direct changes are unsafe and support retest comparison afterward.
Fixes, access modes, and ticket-only fallback
Fix workflows need explicit access, eligibility, credit checks and fallback paths.
Can WebRiskOps apply fixes?
Automated fixes are allowed only for eligible findings, accepted access modes, sufficient credits and implementation paths that can be reviewed and retested safely.
What is ticket-only fallback?
Ticket-only fallback means WebRiskOps creates clear implementation guidance or a support ticket instead of changing code directly when access, risk, eligibility or customer policy blocks automation.
Do you need repository or platform access?
Not for every scan. Fix workflows may need repository, branch, CMS, ecommerce or hosting access, but access is requested only when it is required for the chosen remediation path.
Retest, monitoring, and agencies
Post-report work should show whether findings improved and whether ongoing monitoring is active.
How do retests work?
A retest reruns relevant checks after remediation, compares findings and risk score, and records whether issues were fixed, unchanged or need another action.
What does monitoring include?
Monitoring is meant for recurring checks, status changes, high-risk alerts and summary reporting after a baseline scan exists.
Can agencies resell this?
Agencies can use the product for authorized client properties when account ownership, branding, billing, scope and customer responsibilities are clear.
Data retention, security, and privacy
Customer data is collected and retained only for product delivery, auditability, billing state and request routing.
What data is retained?
The product may retain account, project, submitted URL, scan status, evidence artifacts, reports, billing state, support messages and audit records needed to provide the service.
How are secrets and credentials handled?
Provider secrets, payment data and connected-platform credentials should stay in approved provider systems, encrypted integration boundaries or environment variables, never in public pages or plain-text reports.
Do public report links expose private data?
They should not. Public report links must use tokenized URLs, publish gates, and demo-safe or customer-approved content before anything is shareable.
Limitations and legal boundaries
The product is a technical evidence and workflow tool, not legal, compliance or security certification.
Is this legal compliance certification?
No. WebRiskOps provides technical evidence and operational recommendations; it is not legal advice, compliance certification, security certification or a guarantee that a site is secure or compliant.
Do you provide guarantees?
No automated scan can guarantee future risk-free operation. Reports describe observed findings at scan time and the product workflow needed to address them.
Is this a penetration test?
No. WebRiskOps is not positioned as a pentest. It focuses on authorized automated evidence checks for commercial web journeys and operational remediation workflow.
Troubleshooting and next-step routing
Blocked, failed, unsupported, and unclear states should show the right retry, scope, billing, report or support-form next step.
What if a scan fails?
Failed scans preserve error state, avoid publishing incomplete claims, and show retry, scope-correction or support-form next steps depending on the failure type.
What if I disagree with a finding?
Use the report context and evidence artifacts to review the issue. Findings should be corrected or clarified when evidence does not support the claim.
Where should billing, scan, or fix questions go?
Use the billing page for payment and credit state, the scan page for scan failures, and the report or fix workflow page for finding-specific questions. If the app cannot resolve the question, use the support form with that context.