Help Centre

The composite score (0–100) is a weighted average across all your vendors. It factors in finding severity, business criticality, and data sensitivity. A lower score is better. If the score increases after a scan, new findings were discovered — review them in the Findings page.

All dates on this page reflect your organisation's configured timezone. If dates appear incorrect, check that your timezone is set correctly in Settings. If your organisation has not configured a timezone, your browser timezone is used.

The dashboard displays three distinct trend charts: Findings Trend (count of open findings by severity over time), Vulnerability Trend (CVE exposure broken by severity and showing KEV and high-EPSS overlays), and Risk Score Trend (composite risk score and per-domain scores over time). Findings Trend answers "how many work items are open?", Vulnerability Trend answers "what's our CVE exposure?", and Risk Score Trend answers "is our weighted composite risk improving or worsening?" All three use 30/90/180-day period selectors.

Shows the count of open findings grouped by severity (Critical, High, Medium, Low) over time. Use this to track whether your remediation efforts are keeping pace with new discoveries. If the area above the chart is growing, new findings are accumulating faster than you can resolve them.

Shows the count of open CVE vulnerabilities in your vendor portfolio, grouped by severity (Critical >=9.0 CVSS, High 7.0-8.9, Medium 4.0-6.9, Low <4.0). Two overlay lines highlight higher-risk subsets: KEV (Known Exploited Vulnerabilities from CISA, actively exploited in the wild) and High-EPSS (exploitation probability >=0.1). Use this to focus on actively exploited vulnerabilities requiring urgent patching.

Shows your composite risk score and individual domain scores over time. Seven coloured lines represent the 7 risk domains; a bolder line shows your overall composite score. Use this to track long-term risk trajectory. A rising composite line suggests your vendors are becoming riskier or your exposure is growing; a falling line indicates successful remediation.

The radar chart visualises your organisation’s average risk across 7 domains: Cybersecurity, Operational Resilience, Compliance & Regulatory, Privacy & Data Protection, Financial & Supply Chain, Reputational, and Geopolitical & Sovereign. Each axis shows the domain score (0–100) averaged across all vendors, with the domain weight shown beneath. A larger shaded area means higher risk exposure. Focus remediation on domains extending furthest from the centre — click any axis label to jump to the Findings page filtered to that domain’s controls.

The risk migration chart shows how your vendors move between risk tiers (Critical, High, Medium, Low) over time. Ribbons connecting tiers across time periods indicate vendor transitions — improving (moving to a lower tier) or worsening (moving to a higher tier). Use the period selector (30d/90d/180d) to adjust the time window. If you see many vendors moving toward Critical or High, investigate the underlying findings driving those score increases.

The Assessment Pipeline widget shows how many assessments are in each stage: Draft, Sent, Viewed, In Progress, and Completed. Click any status to review vendors in that stage and take action (send reminders, follow up on stale assessments). The Vendor Assessment Aging widget highlights vendors that are overdue for assessment based on their resolved frequency (considering regulatory cadence, org policy, and vendor criticality). Overdue vendors appear in red — prioritise these first. Due-soon vendors in amber should be scheduled this week. Configure default cadences in Settings › Assessment Policy.

The "Needs your attention" hero section at the top of the dashboard surfaces the single most urgent signal — scan pipeline failures, overdue regulatory notifications, critical findings, stale scans, or other attention items ranked by priority. Click the hero card or its CTA to act on it immediately. The attention rail below lists the remaining signals with non-zero counts.

The "Needs Attention" card aggregates four important signals in one place: vendors with stale scans (not scanned within your configured scan interval, default 30 days), contracts expiring within 30 days, pending assessments awaiting vendor response, and findings assigned to you. Each count is colour-coded and links to the relevant filtered view. If all counts are zero, the card is hidden. Use this card as your daily triage checklist — it highlights the most time-sensitive actions across your vendor portfolio.

New users see a Getting Started checklist on the dashboard for the first 7 days after account creation. It tracks five setup steps: adding a vendor, running a scan, reviewing findings, configuring regulatory frameworks, and inviting team members. The checklist auto-dismisses when all steps are complete, or you can dismiss it manually. Progress is saved per-browser.

If your organisation has a vendor limit (set by your plan tier), you will see a warning banner on the Vendors page when you reach 80% of your limit, and an error state at 100%. Plan tiers: Free (2 vendors), Starter (10 vendors), Essentials (25 vendors), Pro (50 vendors included, per-vendor overage available), Enterprise (50+ vendors, custom negotiated scale). Free-tier organisations also see an Upgrade Plan section on the Settings page showing current usage and a link to billing. To continue adding vendors at the limit, upgrade your plan or archive inactive vendors to free up slots.

The "Contracts Expiring" stat card appears when you have active contracts with end dates within the next 90 days. Click through to the Vendors page filtered to only those vendors with expiring contracts. The daily cron job sends webhook notifications at three severity levels: informational at 90 days, warning at 60 days, and critical at 30 days before expiry.

Dashboard data is automatically cached and refreshed in the background. When you switch tabs and return, the latest data loads instantly from cache while a background refresh fetches any updates. You do not need to manually refresh the page.

If you have a persona assigned (e.g. CISO / Head of Security, GRC Analyst, Security Engineer, Executive), your dashboard shows widgets tailored to your role. CISOs and Executives see higher-level risk summaries, while GRC Analysts and Security Engineers see findings-focused layouts. Users without a persona see the full generic dashboard. Switch personas using the persona selector in the sidebar.

If your organisation is on a free trial, a banner at the top of the page shows the trial status and expiry date. New organisations receive a 14-day trial with Starter-tier features (10 vendors) included at no cost. The banner updates as the trial approaches expiry -- less than 3 days remaining is highlighted in amber to encourage you to upgrade. When the trial expires, your organisation reverts to the Free plan (2 vendors, $0/month). You can upgrade at any time by navigating to Settings > Billing and clicking the upgrade button for your desired tier.

Press Cmd+K (Mac) or Ctrl+K (Windows/Linux) anywhere to open the command palette. Use fuzzy search to quickly navigate to any page, trigger actions (add vendor, export findings), or access help. Arrow keys to navigate, Enter to select, Escape to close.

When switching organisations via the context selector, the dashboard automatically refreshes to show only that organisation’s vendors, findings, and assets. All widgets, charts, and counts update to reflect the selected organisation’s data.

The main sidebar organises navigation into four collapsible groups: Overview (Dashboard, Reports), Vendor Management (Vendors, Products, Technologies, Assessments), Risk and Security (Findings, Vulnerabilities, Assets, Controls, Remediation), and Governance (Compliance, Incidents). Click any group header to expand or collapse its items. The active page's group automatically expands on navigation. Collapse state is saved in your browser so your preferences persist. When the sidebar is collapsed to icon-only mode, all items remain accessible without grouping. Use grouping to reduce cognitive load and focus on related workflows.

The v2 dashboard layout uses a three-tier hierarchy. Tier 1 ("Needs your attention") is always at the top and shows the most urgent signal as a hero card with a supporting attention rail. Tier 2 ("Portfolio summary") shows four compact stat cards: Total Vendors, Composite Risk, Findings Open, and Assessments. Tier 3 ("History and trends") contains charts, assessments pipeline, and recent activity. On mobile, Tier 3 collapses into a "Show more" disclosure. The v2 layout is behind a feature flag (NEXT_PUBLIC_FF_DASHBOARD_V2) and rolls out gradually by org cohort.

The Total Vendors stat card shows your complete organisation vendor count, including unscanned vendors, archived vendors, and those not shown on the current page. This reflects your full vendor roster across all stages. To see only active vendors, use the Vendors page with status filters.

The "Needs Attention" card surfaces the four most actionable signals at a glance: vendors whose last scan is older than the configured staleness threshold (default 30 days), active contracts expiring within 30 days, assessments awaiting vendor response (SENT or VIEWED status), and findings currently assigned to you. Each row links directly to the relevant filtered page so you can act immediately. The card only appears when at least one count is non-zero — when everything is clear, it disappears automatically.

For MSPs with large vendor portfolios, the dashboard summary and vendor list use automatic pagination (default 200 vendors per page). Use the Load More button or scroll to the bottom to fetch additional vendors. This ensures fast dashboard load times even for organisations with thousands of vendors.

The Lifecycle Phase Distribution widget on the dashboard shows a breakdown of your vendor products by lifecycle phase: Full Support, Maintenance, Extended, ELS — paid, End of Life, and Unknown. Each phase segment is colour-coded (green through red). Products in End of Life or Extended phases receive a risk score amplifier, making their associated findings score higher than the same issue on a fully supported product. Click through any segment to see the matching products. This widget helps you prioritise patching or vendor conversations before End of Life dates pass.

ChainShield is a Supply Chain Risk Management (SCRM) platform that continuously monitors the cyber risk posture of your vendors. It uses OSINT-based scanning to automatically discover vendor assets, AI-driven analysis to assess risk, and maps findings to Australian regulatory frameworks including ASD ISM (Australian Government Information Security Manual), APRA CPS 234 (APRA information security standard), CPS 230 (APRA prudential standard), Privacy Act, SOCI Act (Security of Critical Infrastructure), NDB (Notifiable Data Breaches), DFAT sanctions, and the Cyber Security Act 2024. Add a vendor by name and domain — ChainShield discovers everything else automatically.

ChainShield uses context-aware navigation with three view modes: System view (platform-wide administration), MSP view (cross-customer management), and Organisation view (single-organisation data). Use the context selector in the header to switch between organisations. On desktop, use the sidebar to navigate between pages. On mobile, use the bottom navigation bar or the hamburger menu.

After signing in, visit /onboarding to complete your setup. The wizard walks you through naming your organisation, configuring your industry sector and regulatory frameworks, adding your first vendor, and running your first scan. The "Configure Your Organisation" step lets you select an industry sector template (Financial Services, Healthcare, Government, Critical Infrastructure, etc.) to pre-configure your risk domain weights, and choose applicable regulatory frameworks (Australian and international). You can return to onboarding at any time from your profile menu.

ChainShield uses stale-while-revalidate caching powered by TanStack Query. When you visit a page, data is cached locally for 30 seconds. Navigating back serves the cached data instantly while a background refresh fetches any updates. This means you rarely see loading spinners on repeat visits, and the data stays fresh automatically.

The dashboard displays key risk indicators: total vendor count, open findings grouped by severity (Critical, High, Medium, Low), composite risk score, and regulatory exposure summary. Cards are colour-coded by risk level so you can quickly identify areas needing attention.

The composite risk score is a 0-100 weighted average across all your vendors. It factors in finding severity weights, business criticality multipliers, and data sensitivity multipliers. A lower score is better. The score updates automatically after each scan completes or when findings are resolved.

Vendor risk scores are built from a three-level hierarchy. First, each finding gets a risk score (0-100) based on three dimensions: severity (how bad is the issue, from CVSS (Common Vulnerability Scoring System — base severity rating, 0–10) or control criticality), likelihood (how likely is exploitation, using EPSS (Exploit Prediction Scoring System — predicts real-world exploitation probability, 0–100%) data or evidence quality), and context (is the affected system internet-facing, is the software end-of-life). Second, findings are grouped by risk control (e.g. Vulnerability Management, Email Security) and aggregated using a worst-finding-drives model — the most severe finding drives 70% of the control score, additional findings add diminishing returns. This ensures one critical vulnerability always scores higher than many low-severity issues. Third, control scores feed into 7 risk domains (Cybersecurity 40%, Operational Resilience 20%, Compliance 15%, Privacy 10%, Financial 5%, Reputational 5%, Geopolitical 5%), which are weighted and summed into the final composite score.

Risk scores recalculate when the inputs change. Common triggers include: new findings discovered during a scan, EPSS updates (daily refresh of exploitation probability data which changes likelihood scores), a CVE being added to the CISA KEV (Known Exploited Vulnerabilities — actively exploited right now) list (sets likelihood to maximum), a technology reaching end-of-life (adds context bonus to affected findings), findings being resolved or marked as false positives (removes them from scoring), or changes to your org context settings (business criticality, data sensitivity, regulatory designations). Check the Findings tab sorted by "Newest" to see what changed.

The findings trend chart displays open findings grouped by severity (Critical, High, Medium, Low) over 30/90/180 days. This helps you track whether your overall vendor risk posture is improving or if new issues are accumulating faster than they are being addressed.

Each trend chart answers a different question. Findings Trend tracks work items (open issues by severity). Vulnerability Trend tracks CVE exposure and highlights actively exploited vulnerabilities (KEV) and high-probability exploits (high EPSS). Risk Score Trend tracks your weighted composite risk across all 7 domains. Together, they give you a complete picture: how many issues exist, how much are exploitable, and whether your overall risk is improving.

The risk domain radar chart visualises your organisation’s average risk score across the 7 ChainShield risk domains: Cybersecurity (40% weight), Operational Resilience (20%), Compliance & Regulatory (15%), Privacy & Data Protection (10%), Financial & Supply Chain (5%), Reputational (5%), and Geopolitical & Sovereign (5%). Each axis shows the average domain score (0–100) across all vendors. A larger shaded area indicates higher overall risk. Domain weights reflect your organisation’s sector template or custom configuration.

The risk migration chart (Sankey diagram) visualises how vendors move between risk tiers (Critical, High, Medium, Low) over time. Ribbons connect tiers across monthly periods, showing how many vendors transitioned between categories. The summary below shows total improved, worsened, and stable transitions. Use this to understand whether your vendor risk posture is trending better or worse. On mobile, a stacked bar chart is shown instead for readability.

The Needs Attention card is a quick action hub showing four key signals: vendors with stale scans (no scan within your configured interval, default 30 days), contracts expiring within 30 days, pending assessments awaiting vendor response, and findings assigned to you. Click any count to jump directly to the filtered view. The card is hidden when all counts are zero, indicating no immediate action needed. Check this card daily as part of your risk triage routine.

Each organisation may see a different risk score for the same vendor because ChainShield calculates two scores: a global score (`vendors.risk_score`, the baseline from technical findings alone), and a per-organisation score (`organisation_vendors.risk_score`, amplified or dampened by that org's context). The per-org score includes your organisation's specific risk profile: whether the vendor is a material service provider, critical infrastructure dependency, and your custom multipliers for business criticality and data sensitivity. A Critical vendor carries more weight if your organisation operates critical infrastructure; a vendor handling sensitive data gets amplified scoring in organisations that classify data as highly sensitive. If you don't see a per-org score (it shows NULL), your organisation is using the baseline global score instead, which may happen if custom scoring hasn't been configured yet. Configure your organisation's context in Settings > Risk Profile to see a customized per-org score that reflects your actual risk tolerance and dependencies (US-DATA-1046).

Click "Add Vendor" and provide the company name and primary domain (e.g. acme.com.au). ChainShield will automatically discover subdomains, IP addresses, TLS certificates, and email security configuration. The domain must resolve in public DNS and have at least two labels (e.g. example.com, not bare "example"). Industry sector and risk domain weights are configured at the organisation level during onboarding or in Settings. You can also bulk-import via CSV.

Click "Import" on the vendor list to onboard or reconfigure many vendors at once. Download the CSV template first (it lists every accepted column and value, including a legend row to delete before filling it in). Pick a mode: Create adds new vendors and sets their risk configuration in one pass (rows whose domain already exists globally are linked to your organisation rather than rejected); Update edits risk configuration on vendors already in your register, matching rows to vendors by domain first, then by name if no domain is given - it never creates a new vendor. Multi-value columns (Data Sensitivity, Regulatory Scope) use a pipe character to separate values within one CSV cell, e.g. "PII|HEALTH" - a comma would be misread as a new column since commas already separate the CSV fields. Before committing, click "Preview (dry run)" to see exactly which rows will be created, updated, skipped, or rejected with no data written yet; review the plan, then click "Commit import" to apply it. Everything the import/update writes lands on your organisation’s configuration of the vendor (business criticality, data sensitivity, tier, compliance flags, regulatory scope, PCI status, notes, lifecycle stage) - it never touches another organisation’s settings or the vendor’s shared scan data. Newly created vendors with a domain automatically get a first discovery scan queued (unless your organisation has disabled autonomous scanning); linked-existing and updated vendors do not get an automatic rescan from the import itself.

When adding a vendor, the domain is validated in real time. Errors include: "Domain did not resolve" (the domain is not registered or is misspelled - check spelling and wait 5-15 minutes if you just registered it); "Domain resolves to a private IP" (the domain points to an internal network, not public internet); "Timeout" (DNS took too long - retry in a moment). If the error persists, verify the domain is correct and publicly accessible, then contact your administrator.

Tier 1 (Critical): core dependency — breach or outage severely impacts operations. Tier 2 (Important): significant risk with access to sensitive data. Tier 3 (Standard): limited scope, minimal data exposure. Tiers affect scan frequency and risk score weighting.

The same vendor can have different risk scores for different organisations. Set Business Criticality, Data Sensitivity, and regulatory designations (CPS 230 (APRA prudential standard) Material, SOCI Act (Security of Critical Infrastructure) Critical Infrastructure) per vendor to reflect your actual relationship.

When a vendor is first added and has never been scanned, some tabs are hidden to reduce cognitive overload: Findings, Vulnerabilities, Health, and Intelligence tabs are hidden because they would only show empty states. The Overview, Risk, Assets, Products, Technologies, Profile, and Governance tabs remain visible so you can add brand assets and trigger the first scan. The Risk tab is kept because it shows editable compliance fields useful even before a scan. Once a scan completes successfully (even if it finds zero issues), all tabs become visible. Superusers see a "Run First Scan" button in the tab bar for unscanned vendors; organisation users see no scan button.

There is a single on-demand scan action — click "Run Scan" (or "Run First Scan" for an unscanned vendor) to queue the full pipeline: discovery, enrichment (Shodan/Censys, TLS, email security), CVE correlation, AI domain analysis across all 7 risk domains, and compliance mapping. There is no separate Quick/Enrich/Full/Agent mode to choose. Ongoing cadence (how often vendors are automatically re-scanned) is pipeline-managed — see Settings > Scan Schedule.

The Health column shows a 0–100 health score for each vendor, derived from up to 8 metrics including remediation velocity, assessment responsiveness, incident frequency, risk trend, contract status, scan freshness, exit plan readiness, and BCP readiness. Metrics without data are excluded and the remaining metrics are proportionally reweighted. If fewer than 3 metrics have data, the score shows "Insufficient Data". Green (75+) = Healthy, amber (50–74) = Needs Attention, orange (25–49) = At Risk, red (<25) = Critical. Click through to the vendor’s Performance tab for the full breakdown and action items.

The "Risk Domains" column shows 7 coloured dots, one per ChainShield risk domain (Cyber, Ops, Compliance, Privacy, Financial, Reputation, Geo). Each dot reflects the worst open finding severity for that domain. Red = critical open finding; orange = high; amber = medium; green = domain assessed with no open findings; grey = domain not yet assessed. Hover any dot for a breakdown. Findings your organisation has resolved or accepted are excluded from the severity roll-up. On mobile, the column collapses to a single worst-severity dot with a "N domains at risk" count. Click through to the vendor detail page to see the full findings list.

Each vendor inherits the global scan cadence by default (set in Settings > Scan Schedule). A superuser can override it for a specific vendor from the "Scan Cadence" panel on the vendor detail Health tab, entering a custom interval from 1 to 365 days — this is a platform-wide override, not an org-level setting. Critical vendors can be scanned more often while less important ones follow the default schedule. The vendor list shows an estimated "next scan" time based on the effective cadence. A superuser can clear the override at any time to revert to the default.

The "Expiring Contracts" filter tab appears when any of your vendors have active contracts expiring within 90 days. Click the tab to filter the vendor list to only those with upcoming contract renewals. The count badge shows how many vendors are affected. This helps you proactively plan renewals before contracts lapse.

The vendor detail page includes a radar (spider) chart showing scores across all 7 risk domains: Cybersecurity, Operational Resilience, Compliance & Regulatory, Privacy & Data Protection, Financial & Supply Chain, Reputational, and Geopolitical & Sovereign. Scores are adjusted for your organisation’s context — business criticality, data sensitivity, material service provider status, and critical infrastructure designation all amplify or dampen scores at the control level. Toggle between radar and bar views using the icons in the top-right of the Score Breakdown panel. Hover over each axis to see the domain score, weight, weighted contribution, and finding count. When org-level metrics are not available, the chart estimates domain scores from finding severity so you always get a visual risk profile.

The Risk Analysis panel includes a Domain Risk Breakdown with a narrative for each of the 7 risk domains. Click any domain to expand and read the analysis — it explains what was found and why it matters. The Privacy domain analysis includes findings from the vendor’s privacy policy, cookie policy, and terms of service. Use these narratives to quickly understand the "so what" behind each domain score before drilling into individual findings.

Each risk domain shows one of four assessment states. Assessed clean (CLEAN): all controls in this domain were assessed and no gaps were found — the agent confirmed adequate coverage. Gaps found (GAPS): one or more controls have open findings that need review. Insufficient data (INCOMPLETE): the agent ran but could not gather enough evidence for some controls — common causes include no public website, WAF blocking, or agent budget exhausted; these controls show as not yet covered. Pending (NOT_RUN): the domain agent has not run for this scan yet. States update automatically after each scan.

When a rescan adds materially new findings (2+ new CRITICAL/HIGH findings, 3+ novel finding fingerprints, or 20%+ change in total open findings), ChainShield automatically marks the vendor’s AI narrative as stale and schedules regeneration. The Vendor Analysis panel shows a warning banner: "Narrative pending regeneration - [reason]", and the review status pill changes from "Pending" to "Regenerating". The banner disappears automatically once the synthesis agent rewrites the narrative — typically within a few minutes of the rescan completing. If the banner persists for more than 10 minutes, check the pipeline health dashboard or contact your administrator. Narratives with a manual override (locked narratives) are not auto-invalidated; a soft warning is shown instead.

Click any domain on the risk breakdown to expand and see the risk group and control hierarchy. Each domain is divided into risk groups (e.g. Cybersecurity has Attack Surface Management, Transport & Encryption, Application & Access Security, and Security Posture & Emerging). Within each group, controls are listed with their finding count and severity badge. Domains with only one risk group show controls directly. This structure maps to the SCRM risk matrix so auditors can navigate from a specific SCRM reference (e.g. SCRM-02.1) to the exact controls and findings.

The Governance tab consolidates vendor governance information into collapsible sections: Tier & Classification (business criticality, tier, risk context), Compliance & Governance (PCI DSS status, step-in rights, exit strategy, resilience review dates), Contracts (feature-flagged), Business Case, Fourth Parties, BCP Testing, and Exit Plan. Previously, this information was spread across 5 separate tabs plus two sections on the Overview tab. CPS 230 assessors can now complete a full vendor review without switching tabs.

The Profile tab consolidates vendor profile information into collapsible sections: Company Profile (ABR data), Locations, Certifications, Contacts, Resource URLs, and Enrichment. Sections with data expand automatically; empty sections show a "No data" indicator. Resource URLs and Enrichment are collapsed by default to reduce noise. Products and Technologies have their own dedicated top-level tabs for easier access.

The vendor detail page now shows a compact risk score badge inline with the vendor name, visible on every tab without scrolling. The badge is colour-coded: red for critical (>70), amber for high (>50), and green for low (≤50). A dash (-) is shown when no scan has run yet. The last-scanned time is also shown below the vendor domain, giving you a persistent at-a-glance reference for risk posture and data freshness regardless of which tab you are viewing.

Use the refresh icon button in the vendor header to force a risk score recalculation. This re-runs the scoring pipeline (7 domains, 30 controls) using per-finding risk scores, weighted risk calculation, and your org context settings. Useful after manually updating findings, changing vendor criticality, or modifying compliance scope. The button is available to all authenticated users with access to the vendor.

A vendor's risk score populates automatically on scan completion or when a finding's status changes. Vendors added with manually created findings (not from a scan) may show a risk score of 0 or "-" until the scoring pipeline is triggered. If a vendor has findings but shows zero risk score, contact your administrator to trigger a manual rescore. The system monitors for this condition daily and alerts the operations team automatically (US-DATA-579).

When approval workflow is enabled (Settings > Security), new vendors enter Prospect status with a pending approval banner on their detail page. Admin and manager roles can approve or reject with notes. Low-risk vendors (score < 30, Tier 3) are auto-approved on creation. Approved vendors transition to Active status automatically.

The "Pending Approval" filter tab appears on the vendors page when one or more vendors are awaiting an approval decision and you have admin, manager, or owner role. Click it to see only those vendors. Each pending vendor shows an amber "Awaiting Approval" badge alongside its lifecycle stage. Use the Approve and Reject buttons inline to action requests without opening the vendor detail page. Approved vendors automatically transition to Active status via the rpc_process_approval_decision RPC.

Auto-confirm rules automatically confirm discovered assets that match known patterns. Three rule types are supported: Domain Suffix (e.g. ".acme.com.au" confirms all subdomains), ASN Match (e.g. "AS13335" confirms assets on the vendor's network), and IP CIDR (e.g. "203.0.113.0/24" confirms IPs in a known range). Rules can be scoped at three levels: vendor-specific (on the vendor detail page), organisation-wide (in Settings, applies to all vendors in the org), or global (superuser only, applies platform-wide). Vendor rules take precedence over org rules, which take precedence over global rules. First matching rule wins. Rules can be enabled or disabled without deletion.

Use the search bar above the vendor list to filter by vendor name or domain. Search is instant (client-side). The result count updates as you type. Clear the search with the X button to see all vendors again.

The Criticality column in the vendor list shows each vendor's business criticality level (CRITICAL, HIGH, MEDIUM, LOW). Use the Criticality filter dropdown to narrow the list to vendors at a specific criticality level. Sort the column to prioritise highest-criticality vendors. Criticality is set in the vendor's Risk Context section and is especially important for CPS 230 Material Service Provider classifications - higher criticality multiplies risk scores so you give more weight to findings affecting critical vendors.

A small "MSP" badge appears next to vendor names in the list when the vendor is classified as a CPS 230 Material Service Provider. This classification indicates that disruption or failure of this vendor would materially impact your operations under the APRA prudential standard. MSP-classified vendors receive enhanced monitoring, additional compliance obligations, and amplified risk scoring. Filter to "Material SPs only" to focus on vendors with the highest regulatory obligation level.

The vendor overview tab displays a Company Info card showing three enriched data fields when populated: Industry (detected from OSINT and enrichment sources), Employee Range (extracted from LinkedIn, ABR, and company profiles), and Year Founded (from domain registration and business intelligence data). This card provides quick company context without needing to open the full Enrichment Panels. The card is hidden when all three fields are null.

The vendor list uses stale-while-revalidate caching. Data loads instantly from cache while a background fetch checks for updates. When you remove or import vendors, the list refreshes automatically without a full page reload.

When a vendor shows a "Domain unreachable" badge (red), the scan pipeline could not resolve the vendor's domain in public DNS. This typically means the domain is misspelled, lapsed, or has never been registered. Hover over the badge to see the specific error message. Vendor domains cannot be changed after creation - ChainShield uses the domain as a shared identifier across all organisations that have linked the same vendor. If the domain is wrong, remove the vendor (click Remove from your vendor list) and add it again with the correct domain. If the domain is correct but unreachable (e.g. a recently registered or transferred domain), contact your administrator who can reset the scan state once the domain resolves.

The Certifications tab shows security certifications discovered on the vendor's website (ISO 27001, SOC 2, IRAP, etc.). Certifications have three statuses: Unverified (found on website, not independently confirmed), Evidence Found (dedicated certificate page located with cert number/issuer), and Verified (certificate document uploaded). Click "View certificate details" to see the vendor's attestation page. Superusers can manually add, edit, or verify certifications.

The Products tab shows products and services discovered for this vendor. Products are grouped by master product with expandable version rows - click the chevron on any product to see its individual versions and their lifecycle phases (Full Support, Maintenance, Extended, ELS paid, or End of Life). Single-version SaaS products show their phase badge inline without an expand affordance. Use the phase filter chips to focus on products in specific lifecycle states, or use the Extended+, no ELS toggle to quickly surface products in extended or end-of-life phase that are not covered by paid extended support - these are high-priority triage targets. Filters and expansion state round-trip through URL params (?expanded=, ?phase=, ?triage=) so you can bookmark or share a specific view. Use the We use this toggle to mark which products your organisation uses - findings linked to hidden products are excluded from your risk scoring. Bulk select/deselect buttons let you manage large catalogs.

The Technologies tab shows software and services the vendor uses or runs, detected from Shodan/Censys banners, DNS records, and HTTP headers. Technologies are enriched with end-of-life (EOL) status, latest version availability, and known CVE counts. After each scan, AI analysis assigns a risk score (0-100), specific concerns (e.g. "End-of-life since 2023"), and a recommended action (update, replace, monitor, or accept) to each technology. The CVE badge shows the count of open CVE findings linked to that technology. Red "EOL" badges indicate unsupported software requiring immediate attention. Each technology can be linked to multiple assets (e.g. Cloudflare linked to all nameservers, Google Workspace linked to MX records and SPF). Click a technology to see all linked infrastructure in the detail modal.

The Contracts tab on each vendor detail page tracks agreements (MSA, SLA, DPA, NDA, SOW, Licence). Add contracts with start/end dates, renewal dates, values, and auto-renew flags. Contracts expiring within 90 days are highlighted in amber, and those within 30 days in red. A daily cron job checks for expiring contracts and sends webhook notifications so you can plan renewals proactively.

ChainShield assesses vendor financial risk using ABR entity verification, domain age via RDAP, and (when configured) commercial credit bureau data. Financial risk indicators include credit score, payment defaults, ASIC registration status, and insolvency risk probability. Low credit scores or payment defaults generate FINANCIAL_SUPPLYCHAIN findings. This is especially important for CPS 230 compliance where material service provider financial viability must be monitored.

The vendor overview tab shows collapsible intelligence sections when enrichment data is available: Company Intelligence (legal name, industry, entity verification score, physical locations), Financial Health (financial risk score, credit rating, credit score, financial data summary), Sanctions & Compliance (sanctions status with CLEAR/POTENTIAL MATCH badges and match details), and Domain Intelligence (registrar, registration date, expiry with warnings, WHOIS/RDAP data). Sections only appear when the vendor has data for that category.

The SBOM tab shows both the upload interface and a history of all uploaded SBOMs. Click any SBOM to view its detail: component count, validation results, and vulnerability gap analysis including CVE matches. When multiple SBOMs exist, use "Compare Latest" to see what changed between the two most recent uploads - new components, removed components, and changes in vulnerability counts.

When a vendor domain cannot be resolved during the discovery phase, the vendor is marked with a 'Domain unreachable' status and error details are shown. This typically happens when the domain is misspelled, lapsed, or never existed. The vendor will not scan until the issue is resolved. Vendor domains are immutable after creation - if the domain is wrong, remove the vendor and add it again with the correct domain. If the domain is correct but temporarily unresolvable (e.g. DNS propagation delay or a recently transferred domain), contact your administrator who can reset the scan state once the domain resolves in public DNS.

When a vendor shows a red "Scoring Incomplete" data quality flag, the scan pipeline encountered an error in the risk scoring engine but still collected findings. This is a graceful degradation: the scan is marked complete, findings are indexed and searchable, but the risk score was not updated. The flag appears on the vendor detail page and in list views. The vendor shows its last-known-good risk score. The pipeline has automatically queued a rescore attempt via the risk scoring worker. If the rescore succeeds (usually within minutes), the flag clears and the score refreshes. If the underlying issue persists, click the Refresh button in the vendor header to manually trigger a rescore. Contact your administrator if the flag persists.

Use the density toggle (three-row icon group, top-right of the vendor list on desktop) to switch between Compact, Comfortable, and Spacious row heights. Spacious matches the default spacing. Compact is tightest and is useful when reviewing large vendor portfolios. Your preference is saved locally and restored on your next visit. The toggle is hidden on mobile where card layout is used instead. Badges in the vendor name cell overflow into a "+N" chip when there are more than two; click the chip to see the remaining badges without leaving the list.

The Products section of the vendor detail page (Profile tab > Products) shows each product with a lifecycle phase badge and timeline strip per version. The badge names the exact phase: Full Support (green), Maintenance (yellow), Extended (amber), ELS - paid (amber/darker), or End of Life (red). Hover over the badge to see the title tooltip. The timeline strip shows a colour-coded bar from product release to end-of-life with a "today" marker. Days-remaining text below the strip indicates how long until the current phase ends. End of Life and Extended phases amplify risk scores for associated findings - addressing or upgrading these products reduces your vendor's risk score.

Findings linked to products in late lifecycle phases receive a risk score amplifier. Full Support: no amplifier (1.0x). Maintenance: 1.1x. Extended (without ELS): 1.3x. ELS - paid: 1.1x (paid support mitigates some risk). End of Life: 1.5x. The amplifier applies to the cybersecurity domain score, so a HIGH finding on an EOL product scores like a CRITICAL finding on a fully supported product. To remove the amplifier, either upgrade the product to a supported version or purchase extended lifecycle support (ELS/ESU) where available.

If a critical vendor data fetch fails (e.g., pipeline activity, asset discovery), ChainShield displays a banner or toast notification describing the error. The page gracefully degrades - you can still view cached data and manage the vendor while the system retries the fetch in the background. Check the pipeline activity panel or contact your administrator if failures persist.

Navigate to Vendors and click "Add Vendor". You can add vendors three ways: manual entry (name + primary domain), CSV import (bulk upload), or ABN lookup (Australian Business Number search to auto-populate company details). After adding, ChainShield automatically begins an initial scan.

Click "Import" on the vendor list, then "Template" to download a CSV with every accepted column and value (delete the legend row before filling it in). Choose Create to add new vendors and set their risk configuration in one pass, or Update to edit risk configuration on vendors already in your register (matched by domain, falling back to name) without creating anything new. Multi-value columns like Data Sensitivity and Regulatory Scope are pipe-delimited within a single cell (e.g. "PII|HEALTH"), not comma-delimited, because commas already separate CSV columns. Click "Preview (dry run)" first to see the exact create/update/skip/error plan with zero writes, then "Commit import" to apply it - the preview and the committed result use identical row-by-row logic so what you see is what you get. All writes are scoped to your organisation's configuration of each vendor; they never change another organisation's settings or the vendor's shared scan data.

ChainShield validates the domain in real time when you submit. Common rejection reasons: (1) "Domain did not resolve" -- the domain does not have public A or AAAA records. This can happen if the domain is misspelled, not yet registered, or DNS has not propagated (new domains can take 5-15 minutes to propagate after registration -- wait and retry). (2) "Domain resolves to a private IP" -- the domain points to an internal network address, which is not permitted for SSRF safety reasons. (3) "Must have at least two labels" -- the domain you entered is a single-label name like "intranet" without a dot; use a fully-qualified domain like "intranet.example.com". If the domain is correct and publicly accessible but still failing, check your network connectivity and try again.

Vendor tiers classify business impact: Tier 1 (Critical) means a core business dependency where outage or breach would severely impact operations. Tier 2 (Important) indicates significant but not existential risk, with access to sensitive data or systems. Tier 3 (Standard) is limited scope with minimal data exposure or business impact. Tiers affect risk score weighting and scanning frequency.

Tags are custom labels you assign to vendors for organisation-specific grouping (e.g. "finance", "annual-review", "critical-path"). Tags are org-scoped, so each organisation has its own taxonomy. Add tags on the vendor detail page via the + Tag button, entering comma-separated values. Filter vendors by tag on the vendor list page using the tag filter row - filtering is now server-side, so you see matches from all vendors, not just the current page. When you apply a tag filter, pagination resets to page 1 and total count reflects the filtered set. Tags have no effect on risk scoring.

Scanning is a multi-phase OSINT pipeline: (1) Discovery - subdomain enumeration, DNS records, asset identification. (2) Enrichment - port scanning via Shodan and Censys, TLS inspection (HTTPS via SSL Labs + STARTTLS for SMTP/IMAP/POP3/LDAP via sslyze), email security checks (SPF/DKIM/DMARC), SecurityTrails data. (3) CVE correlation and news monitoring. (4) AI analysis - ChainShield's internal AI models generate risk narratives and remediation suggestions (no third-party AI provider receives data). (5) Compliance mapping - findings are automatically mapped to regulatory frameworks. All scans are non-intrusive and use only publicly available information.

No — there is a single on-demand scan action, triggered via the "Run Scan" button on the vendor detail page. It always runs the same multi-phase pipeline: discovery, Shodan/Censys enrichment, CVE correlation, AI domain analysis, and compliance mapping. There is no separate Quick, Enrich, Full, or Agent mode to select from the UI.

Go to Settings and scroll to the Scan Schedule section. Set your organisation-wide default frequency (daily, weekly, fortnightly, monthly, or manual-only) and optionally override individual vendors. Enable the Material Change Trigger to automatically re-scan vendors when significant changes are detected between scheduled scans. The cron scheduler uses these frequencies to determine which vendors are due for scanning.

Vendor risk uses a three-level hierarchy: (1) Per-finding risk score (0-100) combining severity, exploitation likelihood, and context (internet-facing, end-of-life, control weight). (2) Control-level aggregation using a worst-finding-drives model where the most severe finding is the primary driver (70%) and additional findings add diminishing returns (30%). This ensures one critical vulnerability always outweighs many low-severity issues. (3) Domain and composite scoring aggregates control scores across 7 risk domains weighted by importance. Org-context multipliers (business criticality, data sensitivity, CPS 230, SOCI) amplify or dampen scores per organisation.

On each vendor detail page, open the Contracts tab to manage agreements. You can add contracts of various types (MSA, SLA, DPA, NDA, SOW, Licence) with start and end dates, renewal dates, contract value in AUD, and auto-renew flags. Contracts expiring within 90 days are highlighted so you can plan renewals proactively. A daily automated check sends webhook notifications for contracts expiring within 30 days.

Certifications with an expiry date are automatically marked EXPIRED the day after the expiry date passes. A daily cron job runs this check at 03:00 UTC. Update the certification's expiry date to a future date and change the status back to VERIFIED to restore it. This automatic expiry helps you stay aware of certifications that need renewal or replacement.

The 'Scoring Incomplete' flag means the scan collected findings but the risk scoring engine encountered an error before it could compute an updated risk score. The scan is still fully closed - findings are indexed and visible - but the vendor continues to display its last-known-good score until the rescore completes. ChainShield automatically queues a rescore attempt (usually within a few minutes). If the flag clears after that, no action is needed. If it persists, click the Refresh button in the vendor header to manually trigger a rescore. If it still does not clear, contact your administrator - the underlying issue may require a new full scan once the root cause (e.g. a corrupt finding row) is resolved.

The Risk Domains column shows 7 dots, one for each of ChainShield's 7 risk domains: Cyber, Ops, Compliance, Privacy, Financial, Reputation, and Geo. Each dot colour shows the worst open finding severity for that domain: Red = at least one open critical finding; Orange = worst open finding is high severity; Amber = worst open finding is medium (low-only domains show green); Green = domain has been assessed but has no open findings; Grey = no scan data for this domain yet. Findings your organisation has explicitly resolved or accepted are excluded from the count. Hover any dot to see the severity breakdown. On mobile, the 7 dots collapse to a single worst-severity dot with a risk count chip. Click through to the vendor detail page for the full findings breakdown.

Open the vendor detail page and click the Intelligence tab. The tab lists threat-intelligence pulses from 8 registered CTI adapters: CISA AIS, AlienVault OTX, AbuseIPDB, Cloudflare Radar, and four abuse.ch feeds (URLhaus, ThreatFox, MalwareBazaar, SSLBL). The pulses show indicators (IPs, domains, ASNs) observed on the vendor infrastructure in the last 90 days. Confirmed threat exposure materialises under incident_history; adverse_media is reserved for separate adverse-media or stakeholder-trust fallout.

CSP (Content Security Policy) Evaluator is Google's deterministic policy parser that assesses the quality of security headers on your vendor's website. When ChainShield scans HTTP endpoints, it evaluates CSP directives and detects bypassable configurations such as 'unsafe-inline' in script-src. Weak CSP policies are flagged as app_api_security (Application, API & Product Security) findings. A strong CSP reduces XSS exploitation risk.

Vendor dependencies are software packages and libraries detected on the vendor's infrastructure during scanning. ChainShield surfaces these technologies to help you assess supply-chain risk and track which third-party components your vendors depend on. This is particularly relevant for identifying mass-vulnerable dependencies after security advisories or tracking components that appear across multiple vendors in your ecosystem.

ChainShield screens vendors against AU DFAT, US OFAC SDN, UN Consolidated, EU Restrictive Measures, UK OFSI, and Canadian SEMA lists. Japanese METI integration is in progress. Sanctions matches trigger HIGH-severity foreign_influence (Foreign Influence & Sanctions) findings. Checks run weekly and are logged in vendor_sanctions_checks for audit trail.

CRITICAL (25pts, immediate): Actively exploited vulnerability or confirmed breach — immediate risk of data loss, system compromise, or regulatory breach. Triage within hours. Examples: CISA KEV CVE, exposed database with default creds, confirmed data breach. HIGH (15pts, days): Verified exploitable weakness with high likelihood of impact — requires attacker action but path is clear. Plan remediation this week. Examples: High-EPSS CVE (>0.3), exposed admin panel without auth, expired certificate on production. MEDIUM (8pts, weeks): Observable configuration gap or weakness — exploitable but requires specific conditions or attacker sophistication. Schedule for next review cycle. Examples: Missing DMARC/SPF, weak TLS config, missing security headers. LOW (3pts, informational): Minor configuration improvement or limited-evidence observation — low likelihood of exploitation. Examples: Informational CVE (low EPSS), missing best-practice headers. INFO (0pts, observation): No risk — metadata, positive control confirmation, or context for other findings. Examples: PASS findings, verified certifications, technology detection.

Findings can be exported as CSV, PDF, or XLSX (Excel). The XLSX format includes a summary sheet with severity and status breakdowns, plus a detail sheet with auto-filters, auto-sized columns, and date-formatted columns. Use the header export buttons for all findings (with current filters), or select specific findings and use the bulk action bar for targeted exports.

OPEN → IN_PROGRESS → PENDING_REVIEW → RESOLVED. You can also mark findings as ACCEPTED (risk accepted, not fixing) or FALSE_POSITIVE (not actually an issue). Use bulk actions to triage multiple findings at once.

Each finding has a risk score (0-100) calculated from three dimensions: severity (how bad is this issue, based on CVSS for CVEs or control criticality for other findings), likelihood (how likely is this to be exploited, using EPSS prediction data for CVEs or evidence quality for other findings), and context (is this internet-facing, is the software end-of-life, is this a high-weight control). The risk score is the primary sort and priority signal. Higher scores mean greater risk. The breakdown is visible in the risk factors panel on each finding detail page. Note: severity and risk_score measure different things — a CRITICAL severity finding may have a lower risk_score if the issue is historical or low-context; see "Severity vs risk_score" in the engineering documentation for details.

Findings are automatically mapped to Australian regulatory controls (ISM, CPS 234, CPS 230, Privacy Act, SOCI, NDB, Cyber Security Act 2024) via control_id. Each finding maps to one of 30 current controls grouped into 7 scoring domains. Check the compliance tab on finding details to see which specific controls are affected.

When a vendor is shared, each organisation can set their own finding status and priority. One org may accept a risk while another treats it as critical. Overrides don’t affect the underlying finding visible to other organisations.

When performing bulk status changes or deletions, toast notifications confirm the outcome. Success or failure is shown in the bottom-right corner of the screen. If an action fails, retry after checking your connection.

Bulk actions (status updates, exports, deletions) announce their results to screen readers automatically. For example, updating 5 findings announces "5 findings updated to Resolved". Export completions announce "CSV export ready for download". Errors are announced with higher priority so they are not missed.

Use the search bar to filter findings by title, control, severity, or CVE ID. Search is instant with a 300ms debounce and combines with existing severity, status, control, and pillar filters. The result count updates as you type.

Findings are cached and refresh automatically when you change filters or navigate back to the page. Bulk status updates and deletions trigger an automatic cache refresh so the list stays current without a manual page reload.

Use the control filter to narrow findings to a specific risk control (e.g. data_security_retention, platform_email_hardening). You can apply this filter from the findings page filter bar, or by clicking a control row in the Risk tab's Control Breakdown panel on a vendor page. The URL parameter ?control=data_security_retention is shareable. Combine with severity or status filters for precise triage.

Click the "Control Breakdown" tab to see all 30 current controls with their assessment status, severity split, and last finding date. This view shows whether each control is healthy (no open findings), not yet assessed (agent has not run), or has open findings. Click a control row to filter the findings list to that control — this is the fastest way to see all issues affecting a specific control across all vendors. The "Show empty controls" toggle reveals controls with zero findings.

The Control Breakdown view shows all 30 current controls, not just those with findings. Each control has one of three zero states: (a) Green check "Healthy" — the agent ran and found no open issues for this control, (b) Grey dash "Not yet assessed" — the agent has not yet produced findings for this control, or (c) Control is in-scope but the agent has not run for your vendor set. The tooltip on each control explains which state it is in. These distinctions help you understand whether a zero-finding control is genuinely safe or simply not yet assessed.

The findings table supports sorting by severity, status, control, vendor, asset, risk score, and detection date — click any column header to sort. Use the filter bar to filter by control, vendor, severity, or status, and the URL parameter (e.g., ?severity=CRITICAL) is shareable. Column visibility is customizable — click the column icon to show/hide fields like risk score, due date, or regulatory references. Your column preferences are saved per user.

If a vendor has public GitHub repositories, ChainShield automatically checks for open Dependabot alerts and GitHub Security Advisories (GHSA). Only HIGH and CRITICAL severity alerts generate findings to reduce noise. CVEs found via GitHub are deduplicated against those found via Shodan/Censys enrichment.

ChainShield searches GitHub for organisations and repositories associated with a vendor's domain or company name. It uses the GitHub API to collect metadata — stars, forks, open advisories, security policies, licence type, and release signing practices. It does NOT scan source code. Findings are generated for security posture gaps such as missing security policies (SECURITY.md), unsigned releases, unaddressed advisories, and dependency risk indicators. GitHub-sourced findings are categorised by the control that best matches the gap (e.g., attack_surface for unaddressed vulnerabilities, policy_governance for missing governance documentation).

You can create findings that are visible only to your organisation. These org-private findings are shown with an [Org] badge and do not appear for other organisations that share the same vendor. Use "Add Finding" to create one. Org-private findings can be deleted; vendor-level findings discovered by scans cannot. Org-private findings are useful for recording internal assessments, audit observations, or risks specific to your context.

When creating an organisation-private finding, you must select a risk control from the dropdown (e.g. data_security_retention, platform_email_hardening). This control determines which 7-domain the finding contributes to. If you are unsure which control matches your observation, start with the domain most relevant to the issue: Cybersecurity for technical risks (attacks, vulnerabilities), Privacy for data protection concerns, Operational for availability risks, etc. The detailed control descriptions in the dropdown explain what each control covers. After selection, the finding will be mapped to Australian regulatory frameworks automatically.

The "Assigned to me" toggle filters the findings list to show only findings where you are the assigned owner. This filter is applied server-side, meaning it works correctly across all pages — not just the current 50-row page. Use this to manage your personal remediation workload. The assignment can be set on any finding via the finding detail panel. Deep links to the findings page with ?assigned_to_me=true will pre-activate this filter.

A rollup finding groups N underlying items (CVEs or threat-intel indicators) under a single risk control. Rollup rows are marked with a "Rollup: N CVEs" or "Rollup: N indicators" badge. Click the badge to open a drawer listing each member with its ID, severity, and KEV status. Discrete findings (individual CVEs or observations) retain their current display — the rollup badge only appears on findings with kind=rollup.

The "Due soon" toggle filters the findings list to show only findings with a due date within the next 7 days that are still open (not RESOLVED or ACCEPTED). Due dates within 3 days are shown in amber; overdue findings are shown in red. Use this filter to triage findings approaching their deadline. Due dates are set per-organisation via the finding detail panel and are visible only to your organisation.

When the review gate detects a positive finding (e.g. "No confirmed data breach", "Verified Active", "Certifications Confirmed"), it automatically converts the finding from OPEN to PASS. PASS findings represent successful control verification and appear in the findings list but are deprioritised in default views. PASS findings still contribute to compliance metrics and are useful for audit evidence that a control is working. A finding with "PASS" status is not an issue; it confirms the vendor is doing the right thing.

The finding detail card shows which agent discovered the finding in the "Source Agent" field (e.g. Cybersecurity, Operational Resilience, Reputational). This tells you which 7-domain agent ran the analysis. For example, a vulnerability finding from the Cybersecurity agent means it maps to a Cybersecurity control. The source agent is logged for all findings, helping with auditability and understanding the analysis chain.

Use the amber "Evidence gaps" toggle to reveal findings with status EVIDENCE_GAP. These are automatic markers created by the scan pipeline when a risk control could not be positively verified — either because no scan data covered the control, or because the vendor's available evidence was insufficiently authoritative (e.g. a trust page with unverifiable claims). Evidence gap findings contribute to the vendor's risk score via an uncertainty floor (roughly half the maximum score for that control) until positive evidence is provided. Different gap types show distinct messages: control-coverage gaps from the post-analysis agent show "Control not yet assessed -- request vendor documentation" (request SOC 2 report, ISO 27001 certificate, business continuity plan, data residency statement); vendor-blocking gaps from security_txt show "Vendor blocks remote verification -- awaiting direct response" (the vendor's security.txt blocks automated checks — contact directly); enrichment-agent gaps show "Awaiting vendor response" (vendor-supplied evidence awaited). To resolve: contact the vendor with the requested documentation type, then mark the finding RESOLVED. High evidence gap counts on large vendors are structurally expected — many controls cannot be assessed remotely.

A rollup finding aggregates multiple related issues into a single finding for cleaner reporting. For example, a vulnerability rollup combines 50+ unpatched CVEs below the critical threshold into one "CVE Rollup: 50 vulnerabilities" finding. Click the rollup badge (showing the member count) to see a drawer listing all members with severity and CVE ID. Rollup findings have different handling than discrete findings: they contribute to your risk score but are not triaged individually. If a CVE in the rollup crosses a critical threshold (KEV listed, CVSS >= 9.0, EPSS >= 0.8), it is automatically promoted to a discrete finding for dedicated attention.

ChainShield monitors 8 external threat intelligence sources (OTX, AbuseIPDB, CISA AIS, Cloudflare Radar, abuse.ch URLhaus, abuse.ch ThreatFox, abuse.ch MalwareBazaar, abuse.ch SSLBL) for indicators of compromise, active targeting, and malware association affecting your vendors. High-confidence threat intel (TLP RED or AMBER from authoritative sources) generates discrete findings for immediate action. Lower-confidence or routine observations are rolled up into a single vendor-scoped active threat exposure rollup. The Intelligence view on each vendor page shows which sources fired, their latest observation timestamps, and confidence levels.

Some findings are labelled "rollup" — these represent aggregated evidence, such as CVEs contributing to the attack_surface vulnerability control or threat-intelligence pulses contributing to the incident_history threat-exposure control. For attack_surface, ChainShield produces one consolidated rollup per vendor: the title shows structured counts ("X critical, Y high, Z exploitable vulnerabilities found within [vendor]'s infrastructure"). Click the chevron to expand the row and see all contributing evidence references — every non-discrete CVE is included, not just the top 10. Rollup findings are read-only; to address the risk, remediate the underlying CVEs. If a CVE crosses a critical threshold (KEV-listed, CVSS >= 9.0, EPSS >= 0.8), it is automatically promoted to its own discrete finding. An "incomplete scan" badge (grey, no count) means the scan did not gather enough data to assess the control confidently — it is not a risk signal, just a provenance marker.

A rollup finding aggregates multiple related items under a single risk control for cleaner reporting. For attack_surface (vulnerability management, formerly CYBER_01), ChainShield produces one consolidated rollup per vendor rather than one per asset — the title shows counts like "3 critical, 12 high, 4 exploitable vulnerabilities found within [vendor]'s infrastructure". Click the finding to open a drawer listing every contributing CVE with its severity and KEV status (all are included, not just the top 10). If a CVE crosses a critical threshold (KEV-listed, CVSS >= 9.0, or EPSS >= 0.8), it is automatically promoted to its own discrete finding for dedicated triage. Discrete findings without a rollup badge are assessed individually.

ChainShield monitors external threat intelligence sources for indicators of compromise affecting your vendors. When a source detects active threats tied to your vendor's IP ranges, domains, or ASN, the indicators are stored and scored under the incident_history control (Threat Exposure & Incident History). A rollup finding is materialised under incident_history summarising the active threat exposure; its risk score contribution is shown on the vendor Intelligence page. Higher-confidence or authoritative sources (CISA AIS carries the highest weight) increase the score more than community sources like AbuseIPDB. The /vendors/[id]/intelligence page shows which sources have fired, the latest observation timestamp, and the top-10 indicators by confidence.

A finding is a specific security issue discovered by the scan pipeline or AI analysis. Each finding has a severity level, control mapping (control_id), description, recommended remediation, and optionally regulatory references. Findings are deduplicated using two layers: deterministic title normalisation and AI-powered semantic grouping.

Five canonical severity levels are used: CRITICAL (red, 25pts) — actively exploited vulnerability or confirmed breach with immediate risk of data loss, system compromise, or regulatory breach. HIGH (orange, 15pts) — verified exploitable weakness with high likelihood of impact; requires attacker action but path is clear. MEDIUM (yellow, 8pts) — observable configuration gap or weakness; exploitable but requires specific conditions or attacker sophistication. LOW (blue, 3pts) — minor configuration improvement or limited-evidence observation with low likelihood of exploitation. INFO (grey, 0pts) — observation only; no risk, used for metadata, positive control confirmation, or context. For CVE findings, severity is determined by EPSS (Exploit Prediction Scoring System) first, which predicts real-world exploitation probability in the next 30 days. EPSS thresholds: 70%+ = CRITICAL, 30-70% = HIGH, 10-30% = MEDIUM, <10% = LOW. CVSS is used as a fallback only when EPSS data is unavailable (older CVEs). These definitions are stored in the severity_definitions table and injected into all AI agent prompts to ensure consistent classification across the platform.

A control with zero findings has one of two meanings: (a) Healthy — the owning agent ran and found no open issues for this control, shown with a green check, or (b) Not yet assessed — the owning agent has not yet produced findings for this control, shown with a grey dash. Check the Control Breakdown view to see which state applies. If not yet assessed, the agent may still be processing or the vendor may not have scan data for that control yet. If healthy, the control is passing for your vendor.

Findings follow a status workflow: OPEN (newly discovered) -> IN_PROGRESS (remediation underway) -> PENDING_REVIEW (awaiting approval) -> RESOLVED (confirmed fixed). You can also mark findings as ACCEPTED (risk accepted, not fixing) or FALSE_POSITIVE if appropriate. Use the findings list bulk actions to triage multiple findings at once.

Each finding maps to one of 30 current controls via control_id. Controls are grouped into 7 scoring domains (Cybersecurity, Operational Resilience, Compliance & Regulatory, Privacy & Data Protection, Financial & Supply Chain, Reputational, Geopolitical & Sovereign). Controls link to specific regulatory frameworks including ISM, CPS 234, CPS 230, Privacy Act, SOCI, and NDB.

When a vendor is shared across multiple organisations, each organisation can set their own status and priority for shared findings. For example, one org may accept the risk of a finding while another marks it as critical. Per-org overrides do not affect the underlying finding record visible to other organisations.

ChainShield searches GitHub for organisations and repositories associated with a vendor's domain or company name. It uses the GitHub API to collect metadata such as stars, forks, open advisories, security policies, licence type, and release signing practices. It does NOT scan source code. Findings are generated for security posture gaps like missing security policies (SECURITY.md), unsigned releases, and unaddressed advisories. GitHub-sourced findings are mapped to the risk control that best matches the gap (e.g., attack_surface for unaddressed vulnerabilities, policy_governance for missing governance documentation) — there is no legacy category field.

Org-private findings are findings created manually by your organisation that are only visible to your org. They are stored separately from vendor-level findings discovered by scans. Other organisations sharing the same vendor cannot see your org-private findings. They are marked with an [Org] badge in the findings list. You can delete org-private findings, but you cannot delete vendor-level findings (use status overrides instead).

Use the Control filter in the findings page filter bar to select a specific risk control (e.g. platform_email_hardening, data_security_retention). The findings list will narrow to only those mapped to that control. You can also click a control row in the vendor detail page's Risk tab Control Breakdown panel — this filters findings by control and navigates to the findings page with the filter pre-applied. The URL parameter ?control=CONTROL_ID is shareable, so you can send filtered findings views to colleagues. Combine control filtering with severity and status filters for precise triage.

Each finding has a per-finding risk score (0-100) calculated by the v3 scoring engine. The score combines three dimensions: severity (how critical the issue is, from CVSS for CVEs or control criticality for others), likelihood (how likely it is to be exploited, from EPSS data for CVEs or evidence quality for others), and context (internet-facing exposure, end-of-life software, criticality of the affected control). For example, a CRITICAL CVE with high EPSS on a public-facing production server scores much higher than the same CVE on an isolated internal system. The risk score is the primary sort signal for prioritisation — higher scores mean greater business impact. Click a finding to see its Risk Score Breakdown, which shows the calculation formula and component contributions.

The Source Agent field on the finding detail card shows which of the 7 domain agents created the finding. For example, a password-reuse finding comes from the Cybersecurity agent, a business continuity gap from Operational Resilience, and a sanctions match from Geopolitical & Sovereign. The source agent is logged for all findings and helps with auditability and understanding the analysis chain.

Evidence gap messages vary by source: 'Control not yet assessed -- request vendor documentation' means the control could not be verified remotely; request regulatory documents such as SOC 2 Type II reports, ISO 27001 certificates, business continuity plans, or data residency statements. 'Vendor blocks remote verification -- awaiting direct response' means the vendor's security.txt configuration blocks automated verification; contact the vendor directly for evidence. 'Awaiting vendor response' means vendor-supplied evidence is expected (e.g., from a questionnaire or supplementary submission). Each message type indicates which remediation approach to take.

A rollup finding combines multiple related low-severity issues into a single aggregated finding for cleaner reporting. For example, a vulnerability rollup contains 50+ CVEs below the critical threshold that do not warrant individual triage. Rollups show the count of members in a badge (e.g. "Rollup: 42 CVEs"). Click the badge to open a drawer listing all members. Rollups contribute to your risk score but are not triaged individually. If any member crosses a critical threshold (KEV listed, CVSS >= 9.0, EPSS >= 0.8), it is automatically promoted to a discrete finding for dedicated attention.

ChainShield sources threat intelligence from 8 providers: OTX pulses, AbuseIPDB, CISA AIS, Cloudflare Radar, abuse.ch URLhaus, ThreatFox, MalwareBazaar, and SSLBL. Each source checks whether your vendor infrastructure matches known malicious indicators (botnets, C2 servers, malware hosting, phishing kit distribution). High-confidence threat signals (TLP RED or AMBER from authoritative sources) are surfaced as discrete findings for immediate action. Lower-confidence signals or routine observations are rolled up into a vendor-level Active Threat Exposure rollup mapped to the incident_history control (Threat Exposure & Incident History). The /intelligence view on each vendor page shows which sources have fired, with confidence scores and latest observation timestamps.

Discovered assets start as unconfirmed. Confirming an asset marks it as a genuine part of the vendor’s attack surface and activates it for risk scoring. Rejecting removes it from active monitoring. Only superusers and MSP administrators can confirm or reject assets — organisation-level users have read-only access to the asset inventory.

Assets have lifecycle states: Active (monitored), Stale (not seen recently), Retired (decommissioned), and Resolved (issue addressed). Retiring or resolving assets auto-closes linked findings and excludes them from risk scoring.

Each asset is tagged with a hosting location: Domestic (hosted in Australia), Foreign (hosted overseas), CDN Distributed (content delivery network), or Unknown (geolocation could not be determined). This is used for compliance mapping against ISM, PSPF, and CPS 234 data sovereignty requirements.

Use Tab to move between asset rows and Enter to open the detail view. Rows show a visible focus indicator when navigated via keyboard. Bulk actions are available via the selection checkboxes and the floating action bar. All filter dropdowns support full keyboard navigation: arrow keys to browse options, Enter to select, and Escape to close.

Bulk actions (confirm, reject) announce their results to screen readers automatically. When you confirm or reject assets in bulk, an announcement such as "3 assets confirmed" is delivered via an ARIA live region so you know the operation completed without needing to visually check the page.

Asset data is cached locally and served instantly when you navigate back to this page. A background refresh updates the data silently. Bulk actions (retire, resolve, delete) automatically invalidate the cache so you always see fresh results.

Use the search bar in the filter bar to find assets by value (domain, IP, hostname) or type. Search is real-time and filters server-side for fast results even with large asset inventories. Combine search with type, lifecycle, sovereignty, and vendor filters for precise results.

Filter dropdowns show only asset types and sovereignty statuses that exist in your organisation's assets. This bounds the dropdown options to what is actually in use, making it easier to find relevant filters. Filters are organisation-scoped - superusers may see different options than organisation-level users.

Download all assets as CSV via the Export button or the /api/assets/export endpoint.

Assets are digital infrastructure components discovered under a vendor's domain: domains, subdomains, IP addresses, GitHub repositories, and TLS certificates. Each asset tracks open ports, TLS configuration, geolocation, hosting location status, services snapshot, and associated findings.

Hosting location classification is based on IP geolocation of each asset: Domestic (hosted in Australia), Foreign (hosted overseas), CDN Distributed (served via content delivery network), and Unknown (geolocation could not be determined). For foreign-hosted assets, the geopolitical risk profile is assessed separately using country data and geographic concentration analysis. This is critical for compliance with Australian data residency requirements and SOCI Act obligations.

Assets have four lifecycle statuses: Active (seen in the most recent scan), Stale (not seen in recent scans but not yet retired), Retired (manually marked as decommissioned), and Resolved (issue that triggered the asset record is no longer detected). Stale assets are flagged for review as they may indicate shadow IT or decommissioned infrastructure.

Assets are discovered through multiple OSINT methods: DNS enumeration (A, AAAA, MX, NS, TXT records via HackerTarget), SecurityTrails subdomain history, Shodan host enrichment (ports, services, banners), Censys per-IP enrichment (certificates, protocols), and GitHub repository search. New assets discovered in subsequent scans are added automatically.

Firecrawl is a page-rendering integration used during the scan pipeline to handle JavaScript-heavy single-page applications (SPAs). Many modern vendor websites load content dynamically, which means static HTTP requests miss certificates, product details, and security metadata embedded in the rendered page. Firecrawl renders the page in a headless browser and returns the full DOM, allowing ChainShield to extract product information, TLS certificate chains, and other security-relevant data that would otherwise be invisible to the scanner.

Auto-confirm rules let you configure patterns to automatically confirm discovered assets during scans. Three rule types are supported: Domain Suffix (e.g. ".acme.com.au"), ASN Match (e.g. "AS13335"), and IP CIDR (e.g. "203.0.113.0/24"). Rules can be set at three scope levels: vendor-specific (per vendor), organisation-wide (applies to all vendors in your org), or global (superuser only, platform-wide). Vendor rules take highest precedence, then org rules, then global. First match wins. Non-matching assets remain pending for manual review.

The Certificate & TLS tab shows: Subject (CN), Issuer, validity dates (Valid From / Valid Until), protocol version, cipher suite, Subject Alternative Names (SANs), SHA-256 fingerprint, key size and algorithm, and a provenance badge. The provenance badge tells you how the cert was collected: "via bbot" means the scan discovered it passively, "via SSL Labs" means it was verified via the SSL Labs grading API, and "via active probe" means ChainShield performed a direct TLS handshake to fill a gap. Expiry badges show "Expired" (red) when the certificate has expired - this is the only expiry state that generates a finding (HIGH severity). A near-expiry cert with automated renewal is routine operational hygiene, not vendor risk, so it no longer generates a finding (CD-4634) - the tab may still show an informational upcoming-expiry date, but it will not appear on the Findings list. Self-signed certificates are flagged with a HIGH-severity banner. If you see "TLS probe pending", it means port 443 is confirmed open but no cert data has been collected yet - it will appear after the next enrichment run (usually within 24 hours). SHA-256 fingerprint is truncated in the UI; hover over it to see the full value.

"TLS probe pending" appears when the asset has port 443 confirmed open in its services snapshot but no certificate data has been collected yet. This happens when the passive bbot sslcert module did not fire during the initial scan (common on non-standard server configurations) and the active probe has not yet run. The active probe runs automatically during the next enrichment cycle, usually within 24 hours. If the status persists after two enrichment runs, check that the host actually terminates TLS on port 443 (some hosts redirect HTTP traffic on 443 rather than serving a TLS handshake directly).

A certificate approaching expiry is not a finding at all (CD-4634) - only an already-EXPIRED certificate generates one, at HIGH severity. Near-expiry certificates are routine operational hygiene: modern certificate lifecycles (Let's Encrypt and most commercial CAs) auto-renew well before the deadline, so flagging a cert as "expiring soon" produced false-positive escalations on certificates that were never actually at risk. An expired certificate is HIGH because it causes immediate trust failures for end users and indicates a genuine process breakdown - that is the only cert-expiry severity the platform raises. The asset's Certificate & TLS tab still shows an informational upcoming-expiry date so you can track it, but it will not appear on the Findings list until the certificate actually expires.

PHYSICAL_LOCATION assets represent discovered office locations for a vendor. These are automatically created during vendor scans using Google Places data after the business intelligence agent completes. Each location includes geo-coordinates (latitude/longitude), city, state, country, and postcode. Physical locations help identify geographic concentration risk and support data sovereignty assessments.

Controls are displayed in a collapsible accordion grouped by domain. By default, the top 2 worst-scored domains are expanded so you can immediately see your biggest risks. Use the filter bar at the top to search, filter by domain, specific control, vendor, severity, or risk group. All filters sync to the URL, so you can bookmark and share filtered views.

All scores, finding counts, and vendor breakdowns are filtered to your organisation's vendors only. Domain cards are sorted worst-performing first, so your biggest risks are always at the top.

Risk is measured across 7 domains: Cybersecurity (40% weight), Operational Resilience (20%), Compliance & Regulatory (15%), Privacy & Data Protection (10%), Financial & Supply Chain (5%), Reputational (5%), and Geopolitical & Sovereign (5%). Domain weights reflect their relative importance to your organisation's risk posture.

Each control card shows a description of what the control covers and a progress bar showing how many of your vendors pass or fail it. Click the arrow on a control card to open a side panel showing the per-vendor breakdown with scores and severity badges. From there, click any vendor row to jump directly to their findings for that control. This is the fastest way to prioritise remediation by control.

Every control has a description explaining what it covers and why it matters. Hover over or click the control card to see the full description. This helps you understand which controls are relevant to your organisation's context.

Control cards show a quick severity breakdown (e.g., "3 H · 1 M") so you can spot which controls have critical issues at a glance. Regulatory framework badges (ISM, NIST, etc.) show which compliance mappings apply, helping you prioritise by regulatory obligation.

Controls are mapped to Australian regulatory frameworks (ISM, CPS 234, CPS 230, Privacy Act, SOCI, Cyber Security Act 2024). The badges on each control show which regulations are relevant, helping you prioritise remediation for compliance.

ChainShield uses a 7-domain assessment framework with 30 current controls. Those same controls are what agents emit, what scoring engines use, and what the database accepts for new findings.

Monitoring & Detection is the one control ChainShield cannot verify through external scanning at all — there is no public signal that tells us whether a vendor runs a SOC, a SIEM, or has an incident-response runbook. Until a vendor responds to a questionnaire on this topic, the control shows as not-assessed and contributes nothing to the vendor's risk score (it is deliberately excluded from the risk calculation while unverified, so vendors are never penalised for something ChainShield structurally cannot check). It still counts toward your coverage picture, though — a vendor with everything else assessed will show "8 of 9 cybersecurity controls assessed" until this one is answered. Once a vendor provides evidence (a questionnaire response or an artefact like a SOC 2 report), the control starts contributing to the score like any other.

This shows how many of your organisation's vendors have open findings mapped to that control. For example, "3 of 8 vendors failing" means 3 of your 8 vendors have at least one open finding for that control.

A score of 0 means no open findings are mapped to that control — it is in a healthy state. Control scores are driven primarily by the worst finding (70% weight), with additional findings adding diminishing returns (30% weight with harmonic decay). This means the severity of your worst finding matters more than the volume of issues. One critical finding will always score higher than many low-severity findings.

Findings are mapped to risk controls directly by AI agents during analysis. Any unmapped findings are automatically assigned to the appropriate control as a post-processing step.

Domains are sorted worst-first (highest score first) so you can quickly identify where your biggest risks are. This helps you prioritise remediation efforts on the domains that need the most attention.

Click the arrow button on any control card to open a side panel showing all vendors for that control. The panel displays each vendor's score and finding severity breakdown, with links to jump directly to their findings. You can also use the search and filter bar to narrow to specific controls or vendors.

Findings are mapped to 30 controls across 7 domains, each contributing a fixed share of the composite score: Cybersecurity 40%, Operational Resilience 20%, Compliance & Regulatory 15%, Privacy & Data Protection 10%, Financial & Supply Chain 5%, Reputational 5%, and Geopolitical & Sovereign 5%. Cybersecurity dominates because exploitable technical weaknesses are the most common and most severe root cause of vendor incidents. Domain weights can be customised per organisation (Controls > Domain Weight Configuration) subject to a MEDIUM < HIGH < CRITICAL guard on the resulting thresholds.

Every finding is assigned a `control_id` directly by the AI agent that discovered it (e.g. `attack_surface`, `network_exposure`, `data_security_retention`) — there is no separate "category" concept. The 30 controls are current, meaning each one has exactly one owning agent responsible for assessing it. A control’s points contribute to its domain’s raw score; the domain raw score is normalised to 0–100 and multiplied by the domain’s weight; weighted domain scores sum to the composite score (clamped 0–100).

Every vendor carries a global score (`vendors.risk_score`) calculated from ALL of that vendor’s OPEN findings, set when a scan completes. Each organisation that links to the vendor can additionally have its own overlay score (`organisation_vendors.risk_score`) that amplifies or dampens the global score based on that organisation’s context — business criticality, data sensitivity, whether the vendor is a material service provider or critical-infrastructure dependency — and excludes findings that organisation has already RESOLVED or ACCEPTED. When `organisation_vendors.risk_score` is NULL, it means your organisation’s context has not diverged from the defaults, so the dashboard falls through to the global score automatically — NULL is not "unscored," it is "nothing organisation-specific to show."

The numeric 0–100 score maps to a label by default: Critical ≥ 80, High ≥ 60, Medium ≥ 40, otherwise Low. Superusers can adjust these boundaries platform-wide in Admin > Settings > Platform; both the Next.js app and the Python scoring workers pick up a threshold change within 5 minutes with no deploy required.

The Python scoring engine (`worker/scoring/engine.py`, running in the scan pipeline workers) is the single source of truth for every persisted risk score. A parallel TypeScript implementation (`lib/risk-calculation.ts`) exists only to give you an immediate, optimistic score preview in the UI right after you change something — it never writes to the database. The real Python rescore follows automatically via a Redis queue, typically within about a minute, and always wins.

Risk scores also recalculate when finding status changes (resolved, accepted, reopened) or when your organisation’s context fields change (business criticality, data sensitivity, material service provider flag, critical infrastructure flag). Any of these enqueue a rescore job on the Redis `scan:risk_scoring` queue, which the Python `risk_scoring_worker.py` picks up — no fresh vendor scan is required.

You are both looking at the same vendor, but if either organisation’s context has diverged from the defaults (different business criticality, data sensitivity, or resolved/accepted findings), that organisation gets its own `organisation_vendors.risk_score` overlay instead of the shared global score. This is intentional — the same vendor genuinely represents different risk to different organisations.

Domain weighting alone can bury a severe finding in a low-weight domain (e.g. Reputational at 5%). ChainShield applies a severity floor after the weighted composite is calculated: any OPEN CRITICAL finding raises the composite to at least 25, and any OPEN HIGH finding raises it to at least 15, whichever floor is higher applies. This prevents a genuinely severe issue from being mathematically invisible just because of where it landed in the domain taxonomy.

The vendor detail page’s Risk tab breaks the composite score down by domain and control, showing which controls are driving the score and their assessment status. The Controls page shows the full 30-control taxonomy and lets you review domain weight configuration if you have admin access.

Different organisations have different risk appetites. A healthcare provider may weight Privacy & Data Protection higher, while a logistics company may prioritise Operational Resilience. Adjusting weights ensures your composite risk scores reflect what matters most to your business.

Domain weights determine how much each domain contributes to the composite risk score. For example, if Cybersecurity is weighted at 40%, then 40% of the composite score comes from the cybersecurity domain score. All 7 weights must sum to exactly 100%.

If no custom weights are configured, your organisation uses the system defaults: Cybersecurity 40%, Operational Resilience 20%, Compliance & Regulatory 15%, Privacy & Data Protection 10%, Financial & Supply Chain 5%, Reputational 5%, Geopolitical & Sovereign 5%.

Even with custom weights, regulatory auto-uplifts (e.g., CPS 234 raising Cybersecurity to a minimum of 30%) are applied on top of your configuration. This ensures compliance requirements are always met.

New weights are used the next time a vendor risk score is calculated (on the next scan or manual rescore). Existing scores are not retroactively recalculated.

Yes. Use the "Reset to defaults" button to restore the system default weights, then save to persist the change.

Only organisation admins and owners can modify domain weights. Other users can view the current configuration but cannot edit it.

Each regulatory framework (ISM, CPS 234, CPS 230, SOCI, NDB, Privacy Act, Cyber Security Act 2024) shows a coverage percentage based on how many mapped controls have passing findings versus gaps. A coverage of 100% means no active findings affect that framework’s controls.

Drill into any framework to see the specific controls with gaps. Each gap links to the findings that caused it and the vendors affected. Use this to prioritise remediation efforts by regulatory impact.

Export the compliance matrix as CSV for audit preparation, or generate PDF reports for formal evidence. CSV exports include vendor-by-framework scores and gap counts. PDF reports include framework coverage summary, control-level gap detail, and a list of open findings mapped to each control.

Frameworks are determined by your organisation’s regulatory_frameworks setting and per-vendor regulatory_scope overrides. Configure these in Settings (organisation-wide) or on each vendor’s detail page (vendor-specific).

ChainShield supports PCI DSS 4.0 as a regulatory framework for organisations processing payment card data. Findings are mapped to PCI DSS requirements: CVEs to Req.6.3.3 (patching) and Req.11.3.1 (vulnerability scanning), open ports to Req.1.2.1/1.3.1 (network segmentation), encryption issues to Req.4.2.1 (strong cryptography), and governance gaps to Req.12.8.1/12.8.2 (Third-Party Service Provider (TPSP) management). Enable PCI DSS in Settings › Regulatory Frameworks to activate these mappings.

For vendors subject to PCI DSS, track their compliance attestation status (Compliant, Non-Compliant, Not Assessed, Not Applicable) on the vendor detail page. PCI DSS Req.12.8.4 requires annual monitoring of TPSP compliance. ChainShield records the last attestation date to help you track annual confirmation cadence.

Each active vendor contract can be checked against 14 mandatory clause categories derived from Australian regulatory requirements (CPS 234, CPS 230, Privacy Act, NDB, SOCI, ISM). Open a contract in the Vendors page to see the Clause Compliance Checklist. Applicable clauses are filtered based on the contract type and vendor context (e.g. material service provider status, data handling). The compliance dashboard shows an aggregate count of contracts with clause gaps.

Use this widget to identify sub-contractors that multiple vendors depend on — if that sub-contractor fails, all those vendors are affected simultaneously. Sub-contractors used by more than 50% of your critical vendors are flagged as single points of failure. Add fourth parties on each vendor’s 4th Parties tab to build a complete picture, then develop contingency plans for any flagged dependencies.

Expand any domain to see which specific controls are driving risk and how many open findings exist at each severity level. Use this to identify the controls that need the most attention across your vendor portfolio, then click any control to drill into the full Controls page and see which vendors are affected.

ChainShield automatically assesses each vendor for modern slavery risk using three indicators: jurisdiction risk (based on the Global Slavery Index for countries in the vendor's physical locations), sector/industry risk (high-risk sectors include manufacturing, construction, textiles, mining, and agriculture), and revenue threshold applicability (the Modern Slavery Act 2018 requires entities with >$100M consolidated revenue to report). These indicators map to the esg_modern_slavery control (ESG / Modern Slavery Compliance). The Australian Modern Slavery Register is also checked for filed statements. Vendors in high-risk jurisdictions or sectors should receive additional due diligence using the 6 structured assessment questions provided.

ChainShield maps findings to Australian regulatory frameworks (ASD ISM, APRA CPS 234, APRA CPS 230, Privacy Act 1988, SOCI Act, NDB scheme, Cyber Security Act 2024) and international standards including PCI DSS 4.0. PCI DSS mappings cover vulnerability management (Req.6.3.3, Req.11.3.1), network security (Req.1.2.1, Req.1.3.1), encryption (Req.4.2.1), and Third-Party Service Provider management (Req.12.8). Each finding shows which specific controls it relates to.

Risk driver tags on findings are automatically mapped to specific regulatory controls via the compliance mapper. For example, a finding tagged DATA_EXPOSURE maps to CPS 234 controls around information asset classification and Privacy Act obligations. The mapping runs as part of the scan pipeline and appears on finding detail pages and compliance reports.

Material service provider is a designation under APRA CPS 230 (Operational Risk Management). When a vendor is marked as a material service provider, it indicates the vendor provides services that, if disrupted, could have a material impact on the organisation's business operations. This designation triggers additional risk score multipliers and compliance obligations.

NDB Applicable indicates whether a vendor holds personal information that would trigger Notifiable Data Breach obligations under the Privacy Act 1988 (s26WE). When enabled, findings related to data exposure or weak encryption receive regulatory uplift in their business impact scores, and the compliance section flags specific NDB reporting considerations.

ChainShield supports Australian Government ISM data classification levels: OFFICIAL:Sensitive (routine government information requiring basic protections), PROTECTED (information whose compromise could cause damage to national interest), and SECRET (information whose compromise could cause serious damage). Assign the appropriate classification to each vendor based on the sensitivity of data they handle. Higher classifications trigger stricter compliance control requirements and amplify risk scores to reflect the greater potential impact of a security incident.

PCI DSS 4.0 (Payment Card Industry Data Security Standard) is mandatory for any organisation processing, storing, or transmitting cardholder data. ChainShield maps scan findings to PCI DSS requirements and tracks Third-Party Service Provider (TPSP) compliance per Requirement 12.8. You can record each vendor's PCI DSS compliance status (Compliant, Non-Compliant, Not Assessed, Not Applicable) and track annual attestation dates. Enable PCI DSS in your organisation's regulatory frameworks to activate scoring uplifts and compliance mappings.

ChainShield assesses modern slavery risk using three automated indicators: jurisdiction risk (Global Slavery Index data for vendor operating locations), sector risk (high-risk industries like manufacturing, construction, textiles, mining), and revenue threshold ($100M+ triggers Modern Slavery Act 2018 reporting obligations). The Australian Modern Slavery Register is checked for filed statements. Vendors flagged as high-risk should complete a 6-question structured due diligence assessment covering policy, supply chain due diligence, site audits, training, grievance mechanisms, and remediation history. All indicators feed into the esg_modern_slavery control score.

ChainShield checks vendor contracts against 14 mandatory clause categories: Data Protection & Privacy, Breach Notification, Audit & Inspection Rights, Subcontractor Controls, Service Level & Availability, Business Continuity & DR, Data Sovereignty, Termination & Exit, Security Standards, Incident Response, IP & Data Ownership, Insurance & Indemnification, Compliance Reporting, and Change Management. Each clause maps to specific Australian regulatory requirements. Not all clauses apply to every contract — applicability depends on the contract type and vendor context (e.g. material service provider, data handling, critical infrastructure).

Assessments complement automated scanning. Use them to validate internal controls, request evidence of certifications (ISO 27001, SOC 2), collect SBOMs, and verify incident response plans — things that can’t be discovered externally.

When a vendor submits a Software Bill of Materials (SBOM), ChainShield automatically cross-references every component against the NVD (National Vulnerability Database — official US vulnerability registry) using CPE (Common Platform Enumeration — unique software identifier) matching. Vulnerable components generate COMPONENT_VULN_IN_SBOM findings with the relevant CVE ID and CVSS score. If a vendor has been onboarded for more than 30 days without providing an SBOM, a SBOM_MISSING finding is created as a governance gap. Request SBOMs in SPDX or CycloneDX format via the assessment portal.

Create from a template, customise questions if needed, then send via the vendor portal. Vendors receive a unique link — no ChainShield account required. Responses are scored automatically and feed into the vendor risk profile.

Assessment statuses: DRAFT → SENT → VIEWED → IN_PROGRESS → COMPLETED. Overdue assessments appear on the dashboard and can trigger webhook notifications to Slack or Teams.

Vendors complete questionnaires via a multi-step wizard that groups questions by category. Responses auto-save every 30 seconds so vendors can leave and resume without losing progress. A final review step lets them check all answers before submitting. No ChainShield account is required — vendors access the wizard via a unique portal link.

Assessments are structured questionnaires sent to vendors to evaluate their security posture. Create an assessment from a template, customise questions if needed, and send it to the vendor via their portal link. Vendors complete the questionnaire and can attach evidence (e.g., certifications, SBOMs). Responses are scored automatically and feed into the vendor risk profile.

The vendor portal is a public-facing link where vendors complete questionnaires, submit Software Bills of Materials (SBOMs), upload certifications, and respond to remediation requests. Each vendor gets a unique portal URL. No ChainShield account is required for vendors to use the portal.

When a vendor submits an SBOM (SPDX or CycloneDX format), ChainShield automatically cross-references every component against the National Vulnerability Database (NVD) using CPE-based matching. Each vulnerable component generates a COMPONENT_VULN_IN_SBOM finding with the CVE ID, CVSS score, and severity. If a vendor has been onboarded for more than 30 days without providing an SBOM, a SBOM_MISSING governance finding is created. SBOM files are stored in a private, organisation-scoped storage bucket with row-level security.

Assessment lifecycle statuses: DRAFT (created but not yet sent), SENT (delivered to vendor), VIEWED (vendor has opened the link), IN_PROGRESS (vendor has started answering), COMPLETED (all questions answered and submitted). Overdue assessments are flagged in the dashboard and can trigger webhook notifications.

Navigate to a vendor's detail page, click the "Self-Assessment" tab, and start an assessment using the Form sub-tab. The platform ships with a Starter assessment template; future epics will let your org add custom templates.

No. Self-assessments are org-private - only your organisation (and your MSP admin if applicable) can see them. The vendor never sees the answers. This is enforced at the database level via Row Level Security; vendor portal users have zero access to the self-assessment data model.

Each answer maps to a 0-100 score. Rating questions (1-5) map to 0/25/50/75/100. Yes/No maps to 100/0. Yes/No/N/A - N/A is excluded from the average. Numeric values are capped at 0-100. The overall score is a weighted average across all questions in the template; weights are set per question by the template author. Text-only questions do not count toward the score.

Use the Remediations sub-tab. Each remediation ties to a specific response in an assessment. The status flow is: open or in_progress, then resolved, wont_fix, or accepted. Once a remediation reaches a terminal state (resolved, wont_fix, or accepted), it is final in v1. Every status change is recorded in an append-only audit log for compliance traceability.

Click the "History" sub-tab on the Self-Assessment tab of any vendor. You will see a timeline of all submitted assessments with the score, date, and delta from the prior submission. A trend chart at the top of the sub-tab plots the overall score over time.

Submitted assessments are locked, but you can reopen them via the "Reopen" button on the assessment detail. Reopening creates an audit-logged event in the append-only history; subsequent edits are preserved as a separate version. Once you re-submit, the assessment is locked again with the new responses and new score.

A Vendor Questionnaire is supplied and completed by the vendor - visibility is controlled by the vendor and they can see their own responses. A Self-Assessment is completed by your organisation about the vendor - it is org-private and vendors can never see it. The Self-Assessment tab only appears to organisation users and MSP admins; the Vendor Questionnaires page (/questionnaires) lists responses that came from vendors via the portal.

No. Self-assessment data (answers, remediations, history) is org-private and enforced at the database level via Row Level Security. Vendor portal users have zero access to the self-assessment data model - this is verified by an automated filesystem boundary test that runs on every CI build, asserting that no self-assessment or remediation routes exist under app/portal/(authenticated)/.

Create an incident when a vendor experiences a confirmed or suspected security event: data breach, service outage, supply chain compromise, or regulatory non-compliance event. Link affected vendors and related findings for full traceability.

Six types are supported: SECURITY (general), DATA_BREACH (NDB implications), OUTAGE (service disruption), COMPLIANCE (regulatory event), SUPPLY_CHAIN (upstream compromise), OTHER. Use the type filter on the incidents list to narrow down by type. The type determines which notification templates and compliance checklists apply.

If the incident type is DATA_BREACH and the vendor holds personal information (NDB Applicable flag), ChainShield flags the specific NDB reporting considerations under Privacy Act 1988 s26WE. Time is critical — the mandatory notification window is 30 days from becoming aware.

Each incident shows a Regulatory Notifications section listing all applicable notification obligations (NDB, CPS 234, CPS 230, SOCI, Cyber Security Act). Notifications are auto-created based on linked findings and incident type. Each row shows the framework, deadline, countdown timer, and current status. Mark notifications as "Notified" when you have submitted to the regulator, and record evidence notes (reference numbers, dates, contacts) for audit. Overdue notifications appear with a red highlight and are counted on the dashboard.

Navigate to Incidents and click "New Incident". Link the incident to affected vendors and related findings. Add events to the timeline as the incident progresses (detection, containment, eradication, recovery). Each event captures what happened, who acted, and when. The incident timeline provides a complete audit trail.

Six incident types are supported: SECURITY (general security event), DATA_BREACH (confirmed or suspected data breach with NDB implications), OUTAGE (service disruption), COMPLIANCE (regulatory non-compliance event), SUPPLY_CHAIN (upstream vendor compromise), and OTHER. The incident type is shown as a badge on the list and detail views, and can be used as a filter. The type determines which notification templates and compliance checklists are applied.

The incident lifecycle section in the detail panel shows populated timestamps only: Reported, Contained, Resolved, and Closed. Pending steps are not displayed. The APRA Regulatory section appears when either "APRA Notifiable" is flagged or an "APRA Notification Date" is recorded. It shows a Yes/No badge for notifiability and the date the regulator was notified.

When you create an incident and link findings, ChainShield checks each finding’s severity, NDB trigger flag, and compliance mappings to determine which frameworks require notification. For DATA_BREACH incidents, an NDB notification is always created. Deadlines are calculated per framework: NDB (30 days), CPS 234 (72 hours), CPS 230 (10 days), SOCI (30 days), Cyber Security Act (72 hours). You can also manually add notifications from the incident detail view.

Five incident statuses are supported: OPEN (newly reported, under investigation), INVESTIGATING (actively being analyzed), CONTAINED (immediate risk mitigated, root cause analysis ongoing), REMEDIATED (permanently fixed or resolved), and CLOSED (incident complete, post-incident review done). Use the status filter on the incidents list to narrow by stage. The status is shown as a badge on list and detail views.

The default view shows all org-visible vendors that have had at least one threat intelligence source fire in the last 90 days. Click "View as rows" to switch to a filterable, paginated table of individual evidence rows from all 8 CTI adapters (CISA AIS, AlienVault OTX, AbuseIPDB, Cloudflare Radar, URLhaus, ThreatFox, MalwareBazaar, SSLBL). Click any vendor name in the rows view to go to its full intelligence breakdown.

In rows view, use the source pills to show only evidence from specific sources, the severity pills to filter by severity level (rows with no severity are included when no severity filter is set), and the confidence minimum to hide low-confidence observations. All filters are URL-synced - bookmark or share the filtered URL to return to the same view.

Append ?view=rows&vendor_id=<uuid> to the URL to scope the row-level table to a single vendor. A back-link returns to the full portfolio view. You can also click a vendor name in the rows table to go to the per-vendor intelligence detail page.

ChainShield aggregates signals from 8 registered CTI adapters: CISA AIS (authoritative US government indicators, highest weight), AlienVault OTX (open threat exchange pulses), AbuseIPDB (community-reported abuse), Cloudflare Radar (BGP and attack data), URLhaus, ThreatFox, MalwareBazaar, and SSLBL. Evidence is retained for 90 days from detection.

Not all intelligence sources provide a severity classification for every indicator. When severity is absent, the row shows a dash. Use the rows view without a severity filter to include these rows in your results, or add a severity filter to exclude them.

Open the rows view and share/bookmark the URL with ?view=rows&vendor_id=<vendor-uuid> appended, or navigate from the vendor cards view by clicking a vendor and returning to the intelligence page with its ID in the URL.

First, verify the signal — false positives occur. Cross-check the vendor domain, IP address, or hash against the source directly. Contact the vendor to ask for context: is this a honeypot they operate for research, a shared cloud environment, or a legitimate business-use domain? If the signal is confirmed and indicates compromise (e.g., malware C2, botnet member, active intrusion), escalate to a finding and trigger a full security assessment.

ChainShield offers persona-based reports tailored to different audiences: Board Summary (landscape slide deck PDF for C-suite), Executive Summary (CISO/risk manager risk posture), Vendor Deep-Dive (full technical detail for GRC analysts), Vendor Self-Assessment (sanitised report to share WITH the vendor), Compliance Report (framework-first view for auditors), Board Pack / Board & CIRMP (Critical Infrastructure Risk Management Program) Report Pack (10-section CSV for CIRMP governance). Additional exports: Findings Trends, Risk Distribution heatmap.

The Board Summary (the "Board Summary" button) generates a landscape-oriented, slide-style PDF deck suitable for board and executive presentations. It includes six slides: Executive Summary with key metrics, Risk Domain Breakdown across all 7 ChainShield domains, Top Risks with the most critical findings, Compliance Posture showing framework coverage percentages, Remediation Progress with open vs completed trends, and prioritised Recommendations. Each slide uses large fonts and minimal text for readability in presentations. Note: the Board Pack (CSV) is a separate, complementary export for formal CIRMP governance reporting.

Board Summary for board/C-suite presentations (visual-heavy, no CVEs). Executive Summary for CISO/risk managers (domain breakdown, compliance gaps, vendor rankings). Vendor Deep-Dive for GRC analysts (full findings with CVE/CVSS/EPSS, assets, technologies). Vendor Self-Assessment for sharing WITH vendors (sanitised, excludes internal scores and AI narratives). Compliance Report for auditors (framework-first, control coverage, evidence trail). Findings Trends for security teams tracking remediation velocity. Board Pack (CSV) for formal CIRMP governance submissions.

The Vendor Self-Assessment report is designed to be shared directly with vendors. It contains only information appropriate for external recipients: open findings, remediation guidance, compliance gap indicators, and external attack surface summary. Internal fields (AI risk narratives, business impact scores, organisation-specific context) are excluded. Generate from the vendor detail page or the Reports page.

The Compliance Report provides a framework-first view for auditors and GRC teams. It maps findings to regulatory frameworks (ISM, CPS 234, CPS 230, Privacy Act, SOCI Act, Cyber Security Act 2024), shows control-level pass/fail status, and includes an evidence trail of open findings with vendor attribution. Use the "Compliance Report" button in the page header to export as a PDF. Useful for audit preparation and regulatory reporting.

The Board & CIRMP Report Pack is a comprehensive 10-section reporting pack designed for board-level risk governance and CIRMP (Critical Infrastructure Risk Management Program) compliance. It includes: Executive Summary, Material Service Providers, Risk Posture, Compliance Status, Supply Chain Hazards, Incident Summary, Assessment Coverage, Remediation Status, Exit Readiness, and Key Risk Indicators (KRIs). Download as CSV for further analysis or present using the in-app preview.

The KRI dashboard shows 6 traffic-light indicators: Assessment Coverage (>90% green), Exit Plans for Material Vendors (100% green), Critical Findings open >30 days (0 green), Expiring Contracts within 90 days (0 green), Fourth-Party Concentration (<30% green), and Average Remediation Time (<14 days green). Red indicators require immediate board attention. Amber indicators should be monitored. Green indicators are within acceptable thresholds.

The Reports & Exports hub at the bottom of this page lists every available report and data export in one place, grouped by category: Board & Executive (Board Summary, Executive Summary, Compliance, Board & CIRMP Pack), Vendor Reports (per-vendor PDF, Vendor Self-Assessment, Vendor Compare), Data Exports (Findings CSV/PDF, Assets CSV, Vendors CSV), and Registers & Governance (Material Service Provider Register, MSP/CPS 230 Register, RACI Matrix, Audit Trail). Select a vendor using the "Vendor context" dropdown to enable vendor-specific exports. Some exports require admin or manager permissions.

Board Summary, Board Pack, and Executive Summary are restricted to users with the admin or manager role. Compliance, Vendor, and Findings reports are available to all organisation members. If you do not see a report type, your role may not have permission to generate it.

Board Summary, Board Pack, and Executive Summary are restricted to users with the admin or manager role. Compliance, Vendor, and Findings reports are available to all organisation members. If you do not see a report type, your role may not have permission to generate it.

The Board & CIRMP Report Pack download accepts a "days" query parameter controlling the historical window (7 to 365 days, default 90). A 90-day window suits quarterly board packs; extend to 365 days for annual governance reviews.

The Executive Summary maps findings to Australian regulatory frameworks including ISM, CPS 234, and the Privacy Act 1988. Its compliance gap percentage reflects open findings across these frameworks — a lower percentage indicates stronger regulatory alignment.

Eight persona-based report types are available: Board Summary (landscape slide deck PDF for C-suite), Executive Summary (CISO/risk manager portfolio view), Vendor Deep-Dive (full technical detail with CVEs, assets, technologies), Vendor Self-Assessment (sanitised for sharing with vendors), Compliance Report (framework-first view for auditors), Board & CIRMP Pack (10-section CSV with KRI dashboard), Findings Trends (new vs resolved), and Risk Distribution (heatmap). Reports can be exported as PDF or CSV depending on type.

Board Summary and Board Pack are two separate exports designed for different audiences. The Board Summary (formerly "Board Report") is a landscape-oriented slide-style PDF — six slides with large fonts and minimal text, optimised for screen presentation to C-suite and board members. It contains: Executive Summary, Risk Domain Breakdown, Top Risks, Compliance Posture, Remediation Progress, and Recommendations. The Board Pack (Board & CIRMP Report Pack) is a comprehensive 10-section CSV file designed for governance and CIRMP compliance reporting: Executive Summary, Material Service Providers, Risk Posture, Compliance Status, Supply Chain Hazards, Incident Summary, Assessment Coverage, Remediation Status, Exit Readiness, and Key Risk Indicators. Use the Board Summary for board presentations; use the Board Pack for formal governance submissions and CIRMP reporting.

The Board Summary (the "Board Summary" button on the Reports page) generates a landscape-oriented, slide-style PDF deck for board and executive presentations. It includes six slides: Executive Summary (overall risk posture, trend direction, key metrics), Risk Domain Breakdown (7-domain scores table), Top Risks (top 5 critical/high findings with vendor names), Compliance Posture (framework coverage percentages for ISM, CPS 234, CPS 230, Privacy Act, SOCI, and Cyber Security Act 2024), Remediation Progress (open vs completed tasks with trend data), and Recommendations (prioritised action items). Each slide uses ChainShield branding with large fonts and minimal text for readability in presentations.

The Board & CIRMP Report Pack is a comprehensive 10-section reporting pack for board governance and CIRMP compliance. It covers: (1) Executive Summary, (2) Material Service Providers, (3) Risk Posture with top 10 riskiest vendors, (4) Compliance Status by framework, (5) Supply Chain Hazards and fourth-party concentration, (6) Incident Summary with mean time to contain, (7) Assessment Coverage, (8) Remediation Status, (9) Exit Readiness, and (10) Key Risk Indicators with RAG (Red/Amber/Green) thresholds. Sections that depend on features not yet configured (exit plans, fourth-party mapping) degrade gracefully with clear messaging.

KRIs use Red/Amber/Green thresholds: Assessment Coverage (>90% green, 70-90% amber, <70% red), Exit Plans for Material Vendors (100% green, 80-99% amber, <80% red), Critical Findings >30 days (0 green, 1-3 amber, >3 red), Contracts Expiring within 90 days (0 green, 1-2 amber, >2 red), Fourth-Party Concentration (<30% green, 30-50% amber, >50% red), Average Remediation Time (<14 days green, 14-30 days amber, >30 days red).

Findings and assets can be exported as CSV, PDF, or XLSX (Excel). The XLSX format is recommended for working with data in spreadsheets — it includes a summary sheet with severity and control breakdowns, plus a detail sheet with auto-filters on every column, auto-sized column widths, and properly formatted date columns. The Board & CIRMP Report Pack is available as CSV. Use the export buttons in the page header or select specific items and export from the bulk action bar.

Set your organisation name, industry sector, and default regulatory frameworks. These defaults are applied to new vendors and affect which compliance mappings are highlighted in reports.

Configure how often ChainShield scans your vendors. Set an organisation-wide default (daily, weekly, fortnightly, monthly, or manual-only) and override individual vendors as needed. Enable the Material Change Trigger to automatically re-scan vendors when significant changes are detected between scheduled scans. The scan schedule section is in Organisation Settings.

All dates throughout ChainShield — scan timestamps, finding dates, contract dates, assessment due dates — are displayed using a three-level timezone precedence: (1) Organisation timezone set here by admins, (2) individual user profile timezone, (3) browser local timezone as fallback. Set an organisation-wide timezone in the Organisation Settings section under "Timezone" to ensure all team members see consistent date/time display regardless of their individual settings. Selecting "Use user / browser timezone" (the empty option) removes the organisation default and lets each member use their own preference.

Enable "Require approval for new vendors" in Security settings to prevent unvetted vendors from entering your portfolio. New vendors stay in Prospect status until an admin or manager approves them, giving you a gate to verify risk context and compliance scope before monitoring begins. Low-risk vendors (score below 30, Tier 3) are auto-approved to avoid bottlenecks.

Invite team members and assign personas to control their access and UI experience. Personas replace the old role dropdown — each persona automatically sets the underlying role (admin, manager, security, user, viewer) and tailors the UI (landing page, sidebar items, feature flags). Use the inline persona selector next to each team member to change their assignment. The same persona selector is available on the unified admin user management screen (/admin/users) with tier filtering.

ChainShield uses personas to assign roles with tailored UI experiences. Each persona maps to a specific role (determining permissions) plus UI configuration (landing page, sidebar visibility, feature flags). 18 seeded personas are available across four persona groups: system (4), MSP (4), organisation (6), and vendor (4). Seeded personas like "Platform Owner", "MSP Administrator", "CISO / Head of Security", and "Vendor Security Lead" are pre-configured and cannot be modified. When assigning a persona, the underlying role is written to the member table atomically within a database transaction, so existing permission checks continue to work without change. Persona changes are audit-logged and trigger a JWT cache invalidation so the user picks up the new configuration on their next navigation.

Navigate to Settings > Team, select a team member, and choose a persona from the dropdown. The persona determines both the granted role (admin, manager, security, user, viewer) and the UI experience (landing page, visible sidebar items, feature flags). Changing a persona deactivates the old assignment and creates a new one — the full history is preserved in the audit log. Users without a persona assignment continue to work exactly as before (graceful degradation). An admin-initiated backfill script can assign personas to all existing users based on their current roles.

When a persona is assigned to a user, the sidebar navigation and landing page are automatically tailored to their workflow. The persona's ui_config controls which sidebar items are visible (via sidebar_items_hidden), which page loads after login (landing_page), and which optional features are enabled (feature_flags). Superusers and MSP users always see all sidebar items regardless of their persona. Users without a persona assignment see the default sidebar for their role level. Persona configuration uses stable item slugs (not URL paths), so sidebar filtering continues to work even if routes are renamed.

Personas can enable or disable optional UI features via feature_flags in their ui_config. For example, a "General User" persona might have show_financial_data set to false to hide financial columns. Feature flags default to true (permissive) when not specified, so users without a persona or with an incomplete configuration see all features. Admins can preview which features a persona enables before assigning it.

Set up webhooks to receive real-time notifications in Slack, Teams, or custom endpoints. Events include: finding.created, vendor.risk_changed, assessment.completed, scan.completed. All payloads are signed with HMAC-SHA256.

Connect to Jira Cloud to automatically create issues from findings. You need your Jira instance URL (e.g. https://acme.atlassian.net), user email, API token from Atlassian account settings, and a project key (e.g. VRM). Finding severity maps to Jira priority, control mapping maps to issue labels (e.g. attack_surface, cross_border_transfer). Credentials are encrypted at rest. Use "Test Connection" to verify before saving.

Connect to ServiceNow to create incidents from findings. You need your instance URL (e.g. https://acme.service-now.com), username, and password. Optionally specify an assignment group sys_id. Finding severity maps to ServiceNow impact and urgency. The control mapping (e.g. attack_surface, cross_border_transfer) is included in the description for proper classification. Credentials are encrypted at rest.

Once Jira or ServiceNow is configured, click "Create Ticket" on any finding detail page to push it to your ticketing system. The ticket includes severity, control mapping, vendor name, description, remediation plan, and a link back to ChainShield. Only one ticketing system can be active at a time.

ChainShield automatically calculates your billing tier based on active vendor count, total assets, open findings, and regulatory context (material service providers, critical infrastructure designations). Plans: Free (2 vendors, $0/mo), Starter (10 vendors, $490/mo, $49 per extra vendor), Essentials (25 vendors, $975/mo, $39 per extra), Pro (50 vendors, $1,450/mo, $29 per extra), Enterprise (50+ vendors, custom pricing — contact sales). Additional vendors beyond your plan's included count are billed at your tier's per-vendor overage rate. Context factors like material service providers or critical infrastructure can push the tier up. Auto-tier runs after each scan and can be recalculated on demand from Settings › Billing. Admins can disable auto-tier to use a manually set tier.

The Organisation Details section shows your company name, contact email, phone, and active risk sector template. Contact details are editable by admins and saved alongside other organisation settings.

View your current plan tier and vendor count on the Billing page. Check your usage against your plan limit to avoid hitting capacity. If you are approaching your limit, you can upgrade to a higher tier with more included vendors. Trial expiry dates are also shown so you can plan upgrade timing.

Navigate to Settings > Billing to see your subscription status, current charges, and upgrade options. From there you can upgrade to a paid tier via Stripe Checkout, access the Stripe Customer Portal to manage payment methods and view invoices, or check if you have any negotiated rates applied. Billing is managed through Stripe for security and compliance.

Enable the "Require MFA for all members" toggle in the Security section to enforce multi-factor authentication across your organisation. When enabled, all members will be required to set up MFA on their next login.

The Scan Configuration section displays the per-tier scan schedule (full scan frequency and risk refresh frequency). These are configured at the organisation level and determine how often vendors in each tier are scanned.

Any per-vendor scan cadence shown here is a read-only display for audit purposes — it does not affect actual scan timing. The pipeline controls real scan timing based on material changes (new vendor link, compliance change), tier transitions, and automatic max-age sweeps, not a per-organisation tunable setting.

Configure default assessment cadences in the Assessment Policy section. Set the default frequency for all vendors (annual, semi-annual, or quarterly), plus overrides for critical vendors and CPS 230 material service providers. The most stringent frequency always wins — if a vendor is subject to CPS 234 (quarterly) and your default is annual, the quarterly cadence applies automatically. Per-vendor manual overrides can be set from the vendor detail page.

When risk weight changes require approval (configured by your MSP administrator), the "Weight Change Requests" panel appears in Organisation Settings > Risk & Compliance. Pending requests show the proposed weight changes, the requester, and their justification. Any org admin or manager (other than the requester) can approve or reject the change — this four-eyes control ensures material scoring changes are reviewed before they affect vendor risk calculations. Add optional review notes before approving or rejecting. Once approved, the new weights apply immediately and the previous requester sees the outcome in the same panel.

Navigate to Settings > Team and click "Invite". Enter the user's email address and select their role. An invitation email is sent with a one-time link. Pending invitations can be resent or revoked from the same page. Users must create an account (or sign in) to accept the invitation.

Eight organisation roles are available: Owner, Admin, Manager, Security, Compliance, User, Member, and Viewer. Owner and Admin have broad administrative access; Manager handles vendor and assessment workflows; Security and Compliance focus on domain-specific risk work; User and Member provide standard team access; Viewer is read-only. Role assignments can be changed at any time by an Owner or Admin.

Personas are named role profiles that combine a permission role with a tailored UI experience. Instead of assigning a raw role like "manager", you assign a persona like "GRC Analyst" which grants the manager role plus a customised landing page (/findings), sidebar configuration, and feature flags. 18 seeded personas are pre-configured across four persona groups: system (Platform Owner, Platform Operator, Platform Auditor, Platform Scanner), MSP (MSP Administrator, Service Desk, MSP Viewer, Service Delivery), organisation (CISO / Head of Security, GRC Analyst, Security Engineer, General User, Executive, Auditor), and vendor (Vendor Security Lead, Vendor Compliance Officer, Vendor Responder, Vendor Executive). Personas are assignment-time abstractions — the underlying role on the member table remains the authoritative source for permission checks.

Webhooks deliver real-time notifications when events occur in ChainShield. Three webhook types are supported: Generic (sends JSON payload with HMAC-SHA256 signature for verification), Slack (formatted message cards), and Microsoft Teams (adaptive cards). Each webhook endpoint validates payloads using a shared secret.

Available webhook events include: finding.created (new finding discovered), vendor.risk_changed (vendor risk score crossed a threshold), assessment.completed (vendor submitted assessment response), scan.completed (scan pipeline finished), incident.created (new incident logged), and vendor.added (new vendor onboarded). You can subscribe to specific events or all events per endpoint.

Navigate to Settings > API Keys and click "Create Key". Give the key a descriptive name and select the permission scope. API keys are rate-limited based on your plan tier. Keys are shown once at creation time and cannot be retrieved later. Rotate keys regularly and revoke any that are compromised immediately.

ChainShield automatically calculates your billing tier based on your vendor portfolio size and regulatory context. Plans: Free (2 vendors, $0/mo), Starter (10 vendors, $490/mo, $49 per extra vendor), Essentials (25 vendors, $975/mo, $39 per extra), Pro (50 vendors, $1,450/mo, $29 per extra), Enterprise (50+ vendors, custom pricing — contact sales). If you exceed your included vendor count, additional vendors are billed at your tier's per-vendor overage rate. Context factors such as material service providers (CPS 230), critical infrastructure designations (SOCI), high-sensitivity vendors, and large asset footprints can push the tier upward regardless of raw vendor count. Upgrade tiers for volume discounts — no lock-in, no surprises. Auto-tier recalculates after each scan and can be manually triggered from Settings > Billing. Organisation admins can disable auto-tier to use a manually set tier instead.

Risk scores combine finding severity, business criticality, and data sensitivity into a 0–100 composite. Higher-severity findings contribute more to the score. Additional penalties apply for failed assessments, expired certifications, and unresolved critical findings. The score reflects your actual risk exposure — a lower score is better.

Business impact is calculated per finding as: severity base score * criticality multiplier * data sensitivity multiplier * category weight * regulatory uplift. This ensures that a critical finding on a Tier 1 vendor handling sensitive data scores much higher than the same finding on a Tier 3 vendor with minimal data access.

Four org-context multipliers adjust risk scores per organisation: Business Criticality (how critical the vendor is to operations), Data Sensitivity (what level of data the vendor accesses), Material Service Provider (CPS 230 designation for APRA-regulated entities), and Critical Infrastructure (SOCI Act designation). These multipliers mean the same vendor can have very different effective risk scores for different organisations.

In Organisation Settings, you can switch between Default and Custom risk weight modes. Default mode uses the platform-standard domain weights based on your selected sector template (e.g. Financial Services emphasises Cybersecurity and Compliance). Custom mode lets you manually adjust the weight of each of the 7 risk domains to reflect your organisation’s specific priorities. You can revert to defaults at any time with a single click. MSP administrators may also lock weights across managed organisations to enforce consistent scoring methodology.

When your MSP has enabled the four-eyes approval requirement for weight changes, submitting new risk weights creates a pending change request instead of applying them immediately. Another admin or manager in your organisation must review and approve the change before it takes effect. You cannot approve your own request. The "Weight Change Requests" panel in Settings > Risk & Compliance shows all pending requests (always visible, no matter how many) plus the 10 most recent reviewed requests for audit context. Approvers can add review notes before accepting or rejecting. If a technical error prevents the weights from being applied after approval, the system automatically resets the request to Pending so the approver can retry.

ChainShield uses explicit-mapping-only for SSO group authorisation. A user whose IdP groups do not match any active mapping will be rejected at sign-in and shown a generic "Access denied" page. Ensure all active SSO users have at least one mapped group before enabling SSO enforcement.

Admins cannot grant a role higher than their own via group mappings. The database enforces this — an attempt to map a group to "owner" when you are only an "admin" will fail with an error.

When a user belongs to multiple mapped groups for the same tier, ChainShield grants the highest-privilege role. Lower roles from other groups are silently subsumed. The SIEM audit log records which group produced each grant.

Users in that IdP group will lose the associated ChainShield role at their next sign-in or token refresh. If they have no other mapped groups, they will be rejected and shown the access-denied page.

A generic "Access denied — contact your administrator" message. ChainShield never echoes group names or role details back to the browser to prevent information leakage.

Yes. A group can be mapped to an org role and an MSP role simultaneously if the user belongs to both tenants. Each mapping is independent.

Only organisation admins and owners can configure SSO. This restriction prevents standard users from hijacking the domain or provider binding. To grant SSO access to another person, promote them to Admin or Owner role in Settings > Team.

Before registering an SSO provider, claim and verify your organisation domain via DNS TXT. Publish the generated TXT record at _chainshield-verify.<domain> in your DNS zone. Verification takes up to 48 hours for DNS propagation.

If the parent MSP has already claimed your domain, ChainShield returns HTTP 409 (conflict). Contact your MSP admin - they own the domain at the platform level. The ability to override this restriction is planned for a future release (CS-1200).

Domain verification tokens expire 24 hours after generation. If the badge shows "Expired", click "Resend" to rotate the token and restart verification. Your domain claim is preserved - no need to re-claim.

Once verified, select your domain and register your SAML or OIDC provider. You can later delete the provider (users then revert to password login) or add a new provider (the old one is removed automatically). Deactivation is graceful - existing sessions are not terminated.

Not in the current release. If the MSP claims your domain, you get HTTP 409 "domain_claimed_by_parent_msp". This is by design - the MSP admin owns the domain globally. Override support (allowing you to register a separate provider) is planned in CS-1200.

Domain claims are globally unique at the ChainShield platform level. If a sibling organisation verifies your domain first, you receive HTTP 409 "domain_already_claimed_by_another_org". Contact that organisation to release the domain, or ask your MSP admin to move it into your namespace.

Domain verification tokens are valid for 24 hours. Verify before the deadline shown on the page. If it expires, click "Resend" to generate a fresh token and extend the window. The domain claim itself does not expire - only the verification token does.

No. SSO configuration is restricted to Admin and Owner roles for security. Managers can view the SSO settings but cannot make changes. Promote managers to Admin if you need to delegate SSO management.

Users can no longer sign in via SSO; they revert to password-based authentication. The domain remains claimed and verified, so you can register a new provider at any time without re-verifying. Existing sessions are not forcibly logged out.

Use the filter bar to narrow by action type, severity (INFO/WARNING/CRITICAL), resource type, or date range. The search box matches across action descriptions. Combine filters for precise results.

Click "Export CSV" to download a spreadsheet of all filtered events. Use date range filters first to scope the export to the audit period. The CSV includes all columns visible in the table plus full metadata.

Click any row to expand it and see the full change details — including old and new values as JSON. This is useful for understanding exactly what changed during a configuration update.

All significant actions: user logins, role changes, vendor additions/deletions, finding status updates, scan triggers, integration configuration changes, assessment actions, risk weight modifications, and settings updates. Each entry includes the actor, timestamp, IP address, and old/new values.

Yes. Use the "Export CSV" button with date range filters to scope the export. The CSV includes all visible columns plus full metadata. This is useful for CPS 234 and ISM compliance evidence.

Audit logs are retained for 24 months at the organisation level. Platform-level audit logs (admin actions) are retained indefinitely. Logs are immutable once written.

RACI stands for Responsible, Accountable, Consulted, Informed. It defines who owns each governance activity. Accountable (A) means the role that approves the outcome. Responsible (R) executes the work. Consulted (C) provides input. Informed (I) receives updates. ChainShield’s default RACI maps activities like vendor onboarding, risk acceptance, and finding resolution to your team’s personas.

In the current release, RACI assignments are displayed as guidance — the persona badge on decision points tells you who should be performing each action. Server-side enforcement is active on approval workflows (approvals by non-Accountable/Responsible personas are blocked with a 403), but the UI does not prevent navigation. Hard UI enforcement is planned for a future sprint once all organisations have reviewed their RACI.

Create policies as DRAFT, then transition to ACTIVE by providing approved_by and approved_at. When you activate a new policy of the same type, the previous ACTIVE policy is automatically moved to SUPERSEDED to maintain a clean audit trail. Set a next_review_date and ChainShield will email your admin team a reminder 30 and 7 days before the review is due.

Use the "Export CSV" button on the RACI Matrix tab to download the matrix as a spreadsheet for attachment to SCRM-01.1 audit evidence. The export includes all 13 activities and the full persona assignment grid with the template name and export date in the header.

On the Policy Register tab, open a policy record and use the Upload button to attach a PDF, Word, or TXT document (max 10 MB). The document is stored privately and linked to the policy record automatically. Only documents uploaded through this interface are accepted — external URLs are not supported.

The Procurement Assessment tab lets your team self-assess governance maturity across four SCRM controls: Policy & Strategy (SCRM-01.1), Board Oversight (SCRM-01.2), Control Effectiveness Testing (SCRM-02.5), and Contract Management (SCRM-04.2). Each question uses a 0–3 maturity scale (None → Ad hoc → Documented → Optimised). Complete the assessment periodically (e.g. quarterly) using the period key (2026-Q2) to track improvement over time. The resulting maturity score (0–100) is displayed on the Procurement Assessment tab.

A RACI matrix documents who is Responsible, Accountable, Consulted, and Informed for each governance activity. ChainShield uses it to satisfy SCRM-01.1 (supply chain risk management policy), which requires documented accountability for key vendor management decisions. The default matrix covers 13 activities including vendor onboarding, risk acceptance, finding resolution, and board reporting.

Create the policy record (Draft status) using the form on the Policy Register tab. Then open the policy record and use the Upload button to attach a document (PDF, Word, or TXT, max 10 MB). Once the document is uploaded, transition the policy to Active status by providing the approver name and approval date in the policy form.

Any admin or manager can create a draft policy — no additional signoff authority is required. Activating a policy (transitioning from Draft to Active) requires compliance signoff authority as defined in your RACI matrix. This ensures drafts can be prepared by any team member while formal approval remains gated.

Press Shift+? on any page for contextual help. Press Ctrl+K (or Cmd+K on Mac) to open the command palette. Press Escape to close panels and modals.

ChainShield supports standard browser navigation: Tab to move between interactive elements, Enter to activate, Escape to close modals and drawers. The sidebar can be collapsed or expanded to give more screen space for data tables. On data tables, use arrow keys to navigate between rows when a row is focused. Custom dropdowns (user menu, context selector) support full keyboard navigation: Arrow Up/Down to browse options, Enter/Space to select, Escape to close, and Home/End to jump to the first or last option. Tab panels (vendor detail, settings, pipeline) support Arrow Left/Right to move between tabs, Home to jump to the first tab, End to jump to the last tab, and Enter or Space to activate a focused tab. Type-ahead is also supported in dropdowns — typing a letter jumps to the first matching option.

ChainShield targets WCAG 2.2 AA compliance. All interactive table rows have visible focus indicators for keyboard users, modals trap focus and close with Escape, table headers use scope attributes for screen readers, and risk badge colours meet 4.5:1 contrast ratios against the dark background. Bulk actions (status updates, exports, confirm/reject) announce their results to screen readers via ARIA live regions, so you are notified when an operation completes without needing to visually check the page. If you encounter any accessibility issues, please report them to your administrator.

If a scan has been processing for more than 30 minutes, it may be stale. Administrators can check /admin/pipeline, trigger /api/cron/cleanup-jobs with CRON_SECRET, and inspect worker logs if stale jobs keep appearing. If scans consistently fail, verify that external API keys (Shodan, Censys, SecurityTrails) are configured and valid in Admin > Integrations.

If you expect a finding but cannot see it, it may have been auto-deduplicated by the AI deduplication layer. Superusers can check Admin > Global Findings with the "System Statuses" filter enabled. The finding may also have been auto-resolved if the underlying issue was not detected in the most recent scan.

Risk scores are recalculated after each scan job completes. If the score seems stale, check the scan job status on the vendor detail page. Scores also update when findings are manually triaged (e.g., resolved or accepted). If a scan completed but the score did not change, the new scan may not have produced findings that differ from the previous run.

Check the webhook delivery log in Settings > Webhooks. Failed deliveries are retried automatically up to 3 times with exponential backoff. Common causes: the endpoint URL is unreachable, the endpoint returns a non-2xx status code, or the HMAC signature validation is failing on the receiving end. Verify your webhook secret matches what is configured in ChainShield.

ChainShield publishes a public security statement at /security. This page describes the platform’s security practices including data encryption (at rest and in transit), tenant isolation (data isolation between organisations), OSINT-only non-intrusive scanning, API key handling, and responsible disclosure policy. You can share this link with vendors, auditors, or stakeholders who need to understand ChainShield’s security posture. No authentication is required to view the page.

ChainShield assesses vendor financial risk using multiple signals: ABR entity verification (active/cancelled status, entity age, GST registration), domain age via RDAP, and (when configured) commercial credit bureau data including credit scores, payment defaults, ASIC status, and insolvency risk. These indicators generate FINANCIAL_SUPPLYCHAIN findings when thresholds are breached.

During scans, ChainShield automatically discovers and caches key vendor web pages: privacy policy, cookie policy, terms of service, trust centre, security page, about page, and certifications page. Discovery uses fast deterministic strategies (well-known paths, DNS records) combined with an optional LLM-powered Website Discovery agent that crawls the site and searches for hard-to-find pages. These appear in the "Discovered Pages" section on the vendor detail Overview tab. URLs are tagged as "approved" (verified) or "pending" (needs review) and are injected into AI agent context so they can crawl them for deeper privacy and compliance analysis (US-PIPE-767).

Source URLs show which specific web pages an AI agent crawled to produce a finding. For example, a privacy finding might link to the vendor’s /privacy and /cookies pages. These appear in the "Source Pages" section of the finding detail panel, letting you click through to verify the evidence yourself. Source URLs are stored as structured data alongside the finding and are separate from the structured evidence data (scan data including DNS records, HTTP headers, certificates).

ChainShield publishes a public status page showing real-time uptime for the platform. Check the status page — linked in the footer — to see current availability and any active incidents. No login is required.

Auto-resolved findings are automatically purged after 12 months. Audit logs are retained for 24 months. Active findings, vendor records, and assessment data are retained indefinitely while the organisation is active. Stale assets are archived after 90 days of not being seen in scans. Data export is available for compliance archival before records age out.

The audit log records all user actions across the platform: CREATE, UPDATE, DELETE operations with the acting user's identity, IP address, old values, new values, and timestamp. Audit logs cover: user management, vendor changes, finding triage, assessment actions, integration configuration, and system setting modifications. Logs are immutable and retained for 24 months.

Each product is matched against the NVD database to surface known CVEs. Products with unpatched critical vulnerabilities are flagged automatically. Review the version column to confirm whether your vendors are running affected versions.

Upload vendor-provided SBOMs (Software Bill of Materials) to enrich the product inventory with precise dependency data. This improves CVE matching accuracy beyond what external scanning alone can detect.

Products discovered by AI agents start as Pending Review. Admins can confirm (mark as approved), reject (with reason), or un-reject products. Rejected products remain queryable via the status filter. All transitions are logged with user, timestamp, and reason for audit trails. Bulk confirm/reject actions handle large catalogs efficiently.

Unconfirmed products can be confirmed (valid) or rejected (false positive). Rejecting a product opens a reason dialog where you select a category (duplicate, not in use, wrong vendor, other) and optionally add notes. Use the "We use this" toggle to mark products your organisation actually uses. Hidden products are excluded from risk scoring.

The Deployment column shows the product delivery model (SaaS, On-Premise, Hybrid, PaaS, Self-Hosted). The Hosting column shows the first cloud provider with a count of additional providers. Use these to quickly identify data sovereignty and concentration risks across your product portfolio.

Click the Edit button in the Actions column to update usage metadata for any product - criticality (how critical is it to your organisation), usage type (production, staging, development, testing, backup), user count (how many seats your org uses), data sensitivity (which data types flow through it: PII, PHI, Financial, Credentials, IP, Public), a start date, and free-text notes. All org members can edit usage metadata; only admins can confirm or reject products.

Click the history icon on any product row to see a popover showing all state transitions: who triaged it, what state changed to, the timestamp, and (for rejections) the reason category and notes. This audit trail is useful for reconciling why a product has a particular status.

Products are identified by the product_discovery AI agent during scans. The agent analyses vendor websites, technology headers, JavaScript libraries, and marketing pages to build a product catalogue. Products with identifiable CPE strings are automatically matched to CVE databases.

Common Platform Enumeration (CPE) is a standardised naming scheme for software products. When a product has a CPE, ChainShield can automatically cross-reference it against the NVD database to find known CVEs affecting that specific version.

No. When you mark a product as hidden, any CVE findings linked exclusively to that product are excluded from risk scoring. This is useful for products the vendor offers but your organisation does not use.

Click the Edit button (pencil icon) in the Actions column of any product row. The edit modal lets you set criticality, usage type (production/staging/development/testing/backup), user count, data sensitivity tags (PII, PHI, Financial, Credentials, IP, Public), a start date, and notes. Changes are saved immediately and the table refreshes automatically. Any authenticated member of your organisation can update usage details - this does not require admin access.

Rejecting a product marks it as a false positive or out-of-scope discovery (wrong vendor, duplicate, not in use) and removes it from the confirmed list - you supply a reason and those reasons are audited. Hiding a product via the "We use this" toggle means you acknowledge it is real but your organisation does not use it, so it should not contribute to your risk score. Both actions reduce scoring impact, but rejection is the gate for admins to curate the product catalogue.

Each technology detection shows the source (HTTP response header, HTML meta tag, JavaScript library signature, DNS record) and confidence level. Low-confidence detections are marked "Unconfirmed" until an administrator reviews them. High-confidence detections are confirmed automatically.

The Assets section lists the discovered infrastructure components where this technology was detected. If a linked asset is not visible, it belongs to a different organisation's context - this is expected multi-tenant behaviour. Your access boundary is enforced at the asset level via RLS.

Technologies with a confirmed end-of-life date or that are beyond their support window are flagged with an EOL badge. Running unsupported software is a Cybersecurity domain risk factor and generates findings mapped to the Cybersecurity controls. Check the vendor's profile page to see the aggregate EOL exposure.

The Findings section shows all security findings linked to this technology detection. Click any finding to open its detail panel. Findings here are a subset of the vendor's full finding list - filtered to those where this technology is identified as a contributing factor.

Where version information is available (e.g. from HTTP headers or JavaScript library files), ChainShield tracks the specific version detected. Older versions are cross-referenced against the NVD for known CVEs. The version history section shows when each version was first and last seen during scans.

Administrators can confirm or dismiss low-confidence detections from this page. Confirming a detection locks it so it will not be auto-dismissed on future scans. Dismissing a detection removes it from the risk surface and suppresses future detections of the same technology on the same asset.

Yes, indirectly. Technologies with end-of-life status or known CVEs generate findings, and those findings contribute to the Cybersecurity domain score. Dismissing a technology detection also removes its associated findings from the score.

The scan pipeline links technologies to assets across vendor contexts. Assets outside your organisation's access boundary are hidden by RLS, but the count is shown so you are aware they exist. This is expected behaviour. Contact support if the count seems unexpectedly high.

Version data is captured at scan time. If the vendor upgrades their infrastructure between scans, the detected version will be stale until the next scan runs. Tier 1 (Critical) vendors are scanned more frequently, so their technology data is typically more current.

Each version badge names the exact phase: Full Support, Maintenance, Extended, ELS – paid, or End of Life. Hover over any badge for the full phase name and tooltip detail.

The colour bar shows the full lifecycle timeline with a "today" marker. Days-remaining text below the strip tells you how long until the current phase ends.

Product URLs must use http:// or https:// schemes. URLs starting with javascript:, data:, or other non-standard schemes are rejected for security reasons. Provide valid documentation URLs for product information, API documentation, and pricing pages.

Product URLs must use http:// or https:// schemes only. URLs starting with javascript:, data:, or other non-standard schemes are not allowed for security reasons. Update the URL to point to a valid web address, for example: https://docs.myproduct.com or https://www.myproduct.com/pricing.

Your email must match the vendor's registered domain (e.g. alice@acme.com for a vendor with domain acme.com). Personal email addresses will be rejected. This prevents a third party from fronting your vendor record.

After you submit the form, ChainShield emails a confirmation link to the address you entered -- your claim is NOT granted until you click it. This proves you control that mailbox, not just that you know the vendor's domain (CD-5095). Clicking the link brings you back to this page to finish claiming.

If the vendor has already been claimed, sign in with your existing account or contact your vendor admin. If you believe the claim was made in error, contact support@chainshield.com.au.

After finishing the claim you are redirected to your vendor portal dashboard where you can view findings, upload documentation, and manage your security posture. You will also receive a confirmation email.

Navigate to /portal/claim/<your-domain>, register with a work email that matches the vendor's domain, and submit the form. Check your email for a confirmation link -- clicking it brings you back to this page to finish the claim. The claim is atomic -- only one person can claim a vendor. Once claimed, subsequent visitors see an "already claimed" message.

The domain-match requirement prevents third parties from claiming a vendor they do not control. Only an employee with a verified corporate email can self-serve a claim. If your organisation uses a different authoritative domain, contact support.

Matching your email to the vendor's domain alone does not prove you control that mailbox. ChainShield sends a one-time confirmation link to the address you entered, and vendor ownership is only granted after you click it -- this prevents anyone who merely knows a vendor's domain from claiming it on behalf of a mailbox they do not control.

ChainShield aggregates threat intelligence from 8 registered CTI adapters: CISA AIS (authoritative US government indicators - highest weight), AlienVault OTX (open threat exchange pulses), AbuseIPDB (community-reported abuse), Cloudflare Radar (BGP and attack data), and four abuse.ch feeds covering URLhaus, ThreatFox, MalwareBazaar, and SSLBL malware/botnet indicators. A source showing "Active indicators detected" means at least one indicator from that source was observed on your vendor's infrastructure within the last 90 days.

The incident_history score contribution shows how much active threat intelligence is adding to the vendor's Cybersecurity domain risk score. A higher score means more or higher-confidence indicators have been detected. This contribution is recalculated whenever a new scan materialises threat-intel findings via the Python scoring engine.

The top-10 indicators are the highest-confidence threat signals observed in the last 90 days. Indicators are IP addresses, domain names, or ASNs associated with malicious activity. They are shown as text only - do not attempt to visit any indicator values as they may be malicious infrastructure.

Intelligence data is refreshed automatically during each vendor scan cycle. The last-refresh timestamp next to each source shows when indicators were last collected. Tier 1 vendors scanned daily will have more frequent updates than Tier 3 vendors on weekly cycles.

"Not fired" means no indicators from that source were observed for this vendor's infrastructure in the last 90 days. This is informational - it does not mean the vendor is safe, only that no signals were received from that specific source in the observation window.

Accepting the invitation confirms your email and assigns you to the team (organisation or MSP) with the role specified by the inviter (e.g. admin, manager, viewer). You will immediately see the team's vendors and findings.

Team invitations expire after 7 days. If your link has expired, ask the team admin to send a new invite. If you already have a ChainShield account, you may be able to self-join if the team has open invitations enabled.

You can be a member of multiple organisations (if you work with multiple MSPs or clients) or multiple roles within the same organisation. After accepting this invite, you can switch between teams using the team selector in the app.

If you are already a member of this team, you will see a message confirming this. No action is needed — you already have access.

Accepting the invitation confirms your email address and creates a persistent portal session. You will be able to sign in to the portal without needing a new invite link each time.

The organisation that invited you may require you to sign in with a password or via your company's single sign-on (SSO). Follow the prompts to complete sign-in.

If you don't have an account yet, choose "Create Account". We'll email a secure set-up link to the invited address — click it to set your password, then you'll land back on this page to accept the invitation. Only the invited mailbox can activate the account; the invite link alone is never enough.

You will have immediate access to your vendor dashboard, findings, and assessment questionnaires. Start by reviewing your risk score and outstanding findings.

The top bar of this page shows the name of the organisation assessing your vendor risk. This trust indicator helps you verify you are communicating with the correct organisation.

This page covers several distinct denial reasons (SSO group mapping missing, SSO enforced but you tried password login, MFA required but not completed). The heading and message on the page itself tell you which one applies — ChainShield deliberately does not disclose extra detail here (no group names or internal error codes) to avoid revealing information useful to an attacker probing your organisation's login setup.

Contact your organisation administrator. If the message mentions SSO, confirm with them that your account is assigned to the correct identity-provider group and that you are using the "Sign in with SSO" option rather than a password. If the message mentions MFA, complete multi-factor verification and try again, or ask your administrator to reset MFA if you have lost access to your authenticator app.

ChainShield aims to conform to WCAG 2.2 Level AA (Web Content Accessibility Guidelines). We comply with the Australian Disability Discrimination Act 1992 (DDA), which requires equal access to digital services for people of all abilities.

All interactive elements are keyboard accessible. Screen readers are supported with ARIA labels. Risk severity is indicated by both colour and text label — information is never conveyed by colour alone. Focus indicators are visible on all buttons and links.

If you encounter an accessibility problem, please contact accessibility@chainshield.com.au with a description of the issue and the page URL. We aim to respond within 5 business days and fix verified issues promptly.

View your display name, email, role, active persona, and organisation memberships. Navigate to Settings > Account to make changes.

If you belong to multiple organisations, they are listed here. Use the context selector in the header to switch between them. Each organisation may give you a different role.

See your active browser sessions and their last activity timestamps. Revoke sessions from unknown devices or locations to protect your account.

Use the context selector in the sidebar header. Click the current organisation name and select a different one from the dropdown. All pages update to show the selected organisation's data.

Navigate to Settings > Security to change your password and MFA settings, or Settings > Notifications to manage email and webhook preferences.

Go to Settings > Security > Setup MFA. Scan the QR code with your authenticator app and enter the verification code. Save your recovery codes securely.

Your display name is shown in audit logs, comments, and assignment lists. Keep it recognisable so team members can identify your actions. Email changes may require re-verification.

Review your active sessions and sign out of any you do not recognise. Enable MFA (multi-factor authentication) from the Security settings page for an additional layer of protection on your account.

After entering the vendor name and domain, choose Quick Add to create the vendor immediately with sensible defaults, or Configure First to set business criticality, vendor significance, and compliance frameworks before creation. Quick-added vendors show a "Risk context not configured" banner on their detail page so you can complete configuration later.

This step captures how critical the vendor is to your regulatory obligations. Flags like Material Service Provider (CPS 230), Critical Infrastructure Asset (SOCI), and PII handling drive risk score multipliers. A vendor marked as a Material Service Provider will have higher weighted scores across operational resilience controls.

Select which compliance frameworks findings should be scored against. Frameworks inherited from your organisation settings appear pre-selected and cannot be removed per-vendor. You can add additional frameworks specific to this vendor relationship. Framework selection amplifies risk scores for findings mapped to those frameworks.

Agent rules are instructions that AI agents read before analysing a vendor. They encode lessons learned from analyst corrections and rejected findings. For example, a "suppress" rule can prevent agents from flagging TLS 1.2 as a risk, while a "calibration" rule can adjust how agents weight certain controls.

Suppress: prevent specific finding types from being created. Severity Override: change the default severity for a finding pattern. Instruction: provide freeform guidance to the agent. Calibration: adjust scoring weights or thresholds for specific controls.

Each vendor also has per-vendor agent context entries visible on the vendor detail page. These are created automatically when findings are rejected (with notes explaining why), or manually by analysts. Vendor context is more specific than global rules and takes precedence during analysis.

Global agent rule management (creating, editing, and toggling rules that apply across all vendors) has moved to the Admin section at /admin/agent-rules. This page now shows organisation-level rules only. If you previously bookmarked the settings agent-rules page for global rule management, update your bookmark to /admin/agent-rules.

This page displays your new API key exactly once. Copy it immediately to a secure location. This link is single-use and will be invalidated as soon as you leave this page or close the browser tab. If you lose the key before copying, you will need to request a new reveal link from the migration email or from API Keys settings.

Copy your new API key, then update all your integrations and applications to use the new key. Do not embed the key directly in code; use environment variables or a secrets manager. Once all integrations are updated, you can revoke the old key from the API Keys settings page.

No. The key is shown only on this page, one time. Copy it immediately. If you lose it, return to the migration email and request a fresh reveal link, or go to your API Keys settings and create a new key.

One-time-use links prevent accidental key exposure through browser history, cached pages, or forwarded emails. The security benefit of preventing multiple views outweighs the inconvenience of copying once.

Click "Create Key" to generate a new API key with a minimum of 32 characters. Give it a descriptive name and select permission scopes: vendors:read, findings:read, scans:write, reports:read, msp:read, etc. The key is shown once at creation — copy it immediately.

Assign only the minimum permissions each integration needs. For a monitoring dashboard, vendors:read and findings:read are sufficient. For triggering scans, add scans:write. To mark findings as Resolved, Accepted, or False Positive via API, add the "Resolve Findings" (findings:resolve) scope — this scope gates scoring-affecting status changes and must be explicitly granted. Broad scopes increase risk if the key is compromised.

Rotate API keys regularly — create a new key, update your integration to use it, then revoke the old key. Never embed API keys in client-side code or version control.

If your integration is being throttled, check the X-RateLimit-Remaining response header to see how much quota remains. Defaults: 120 requests/minute for authenticated endpoints, 2,000/hour for heavy endpoints (e.g. scan triggers). Brute-force protection enforces rate limiting per API key to prevent credential guessing attacks. Contact your admin if you need higher limits for your plan tier.

Your API keys are protected with industry-standard cryptographic hashing. If you receive an email titled "Migrate your API Key", ChainShield is upgrading older keys to a stronger format. Your old key continues to work for 30 days. Click the secure "Retrieve New API Key" link in the email to retrieve the new key (the link expires in 15 minutes). Copy the new key immediately, update your integrations to use it, then the old key will be automatically retired after 30 days.

Your browser session includes a one-hour CSRF security token. If you see a "session expired — retry" error when creating, rotating, or revoking a key, refresh the page to obtain a new token and try again.

No. API keys are shown once at creation time and cannot be retrieved later. If you lose a key, revoke it and create a new one. This is a security measure to prevent key exposure.

Include the key in the Authorization header as a Bearer token: "Authorization: Bearer <your-api-key>". All API endpoints accept this authentication method. See the API Documentation page for endpoint details and examples.

Revoke it immediately from this page. Create a new key with the same scopes and update your integration. Review the audit log for any unauthorized API calls made with the compromised key.

MFA enforcement only applies to interactive (browser) logins with valid user sessions. API key authentication is separate and machine-to-machine - it does not require MFA verification. API keys are not affected by MFA settings on your organisation.

Ensure the API key has the "findings:read" scope and the key's organisation is linked to the vendors you're querying. Findings are scoped to vendors your organisation owns. Check that the vendor appears in your vendor list before requesting findings for it.

ChainShield automatically migrates older API keys to a stronger format for improved security. Your old key continues to work for 30 days from the email date. Click the secure "Retrieve New API Key" link in the email — this link is valid for 15 minutes and can only be used once. Copy the new key immediately when the page loads, then update your integrations. If the link has expired, log in here and create a new API key.

Yes. Your old key continues to work for 30 days from the date of the migration email. After that it is permanently deactivated. Update your integrations to use the new key before the expiry date shown in the email.

API key reveal links are one-time-use only for security. Once you click the link and view your key, the link is immediately invalidated to prevent it being accidentally shared or compromised. If you need to retrieve the key again, request a fresh link from the migration email or from the API Keys page in your account settings.

The endpoint list on this page is rendered directly from public/openapi.json — the same machine-readable contract served for download — so it can never drift out of sync with the real API surface (CS-2224).

Two methods: API keys (Bearer token in Authorization header, created in Settings > API Keys) and browser session cookies. API keys support scoped access — assign only the permissions each integration needs (vendors:read, findings:read, scans:write, etc.). Each endpoint below shows the scope it requires; endpoints badged "Session auth only" need an authenticated browser session instead of a scope, and those badged "No auth required" are public routes callable without credentials.

Download the OpenAPI 3.1 JSON spec to import into tools like Postman, Swagger UI, or code generators. The spec covers every v1 operation across vendors, findings, assets, assessments, CVEs, and more.

Check the X-RateLimit-Remaining response header to monitor your usage. Rate limits are configurable per tier in Admin > Settings > Platform. Default limits: authenticated 120 req/min, public 30 req/min, heavy (scans) 2,000/hour. Changes take effect within 5 minutes across all instances.

Assessments follow a lifecycle: DRAFT (created, not sent) -> SENT (delivered to vendor) -> VIEWED (vendor opened the link) -> IN_PROGRESS (vendor started answering) -> COMPLETED (all answers submitted). Track progress from this page.

Once a vendor submits responses, review each answer. Yes/no and multiple choice questions are scored automatically. Free-text and file-upload questions require manual review scoring. Add reviewer notes for audit purposes.

The overall assessment score feeds into the vendor risk profile. Low-scoring assessments (below 50%) generate findings that map to relevant compliance controls. The score appears on the vendor detail page and in reports.

Vendors can attach files (ISO certificates, pen test reports, SBOMs, SOC 2 reports) alongside their questionnaire responses. Evidence files are scanned for malware and stored in encrypted, organisation-scoped storage.

If a vendor has not responded, resend the assessment from this page. Overdue assessments can trigger automated reminder emails and webhook notifications. Configure reminder cadence in Settings > Assessment Policy.

Create the assessment (from a template or scratch), customise questions if needed, then click "Send". The vendor receives a unique portal link via email — no ChainShield account required. They complete the questionnaire through a guided wizard with auto-save.

You cannot change questions after sending (this would invalidate vendor responses). You can add reviewer notes, resend the link, and change the deadline. To ask different questions, create a new assessment.

The status changes to COMPLETED, a scan.completed webhook fires, and the assessment score is calculated. Low-scoring sections may generate findings. The score feeds into the vendor risk profile and appears in reports.

Export as PDF for formal evidence or CSV for data analysis. The export includes questions, vendor responses, scores, reviewer notes, and any attached evidence references. Useful for CPS 234 and CPS 230 audit preparation.

The History tab lists all submitted assessments in reverse chronological order (newest first). Each row shows: submission date, overall score, change from the previous assessment (delta), and a link to view the full assessment details. Archived assessments are hidden by default but can be shown via a filter toggle.

The trend chart shows your assessment scores plotted over time. A rising line suggests improving vendor capability. A falling line suggests declining performance or newly-discovered gaps. Use the chart to spot seasonal patterns or correlations with vendor incidents, contract renewals, or organisational changes.

Click "View Full Assessment" on any row to see all questions and responses for that submission. Compare two assessments side-by-side by opening them in separate browser tabs. Look for questions where scores changed significantly and investigate why (e.g. staff turnover, system upgrades, policy changes).

There is no automatic reminder system in v1. Set a calendar reminder to re-assess vendors on a regular cadence (quarterly, biannually, annually). Critical vendors may warrant more frequent re-assessment.

Assessments only appear after they are submitted. A draft assessment (in-progress) is not shown in History; it remains in the Form tab until submission. Once you submit the first assessment, it will appear in the History tab.

No. Assessments can only be soft-archived (hidden from view but retained for audit). Hard deletion is not allowed to preserve the compliance trail. To hide an archived assessment, filter them out using the "Show archived" toggle.

The delta is the difference between the current assessment's overall score and the previous submitted assessment's score. A positive delta means the score improved. A negative delta means it declined. If there is no previous assessment, the delta is blank (not applicable).

See all questions grouped by section with their types, weights, and scoring rubrics. The preview shows exactly what vendors will see when completing the questionnaire.

System templates are read-only. Click "Clone" to create your own editable copy. Add, remove, or reorder questions. Your cloned template appears in the "My Templates" section.

See how many assessments have been created from this template, completion rates, and average scores. This helps evaluate whether the template is effective.

No. System templates are read-only to ensure consistency. Clone the template to create your own editable version. Your cloned copy is fully customisable.

Template changes do not affect assessments already sent. Only new assessments created from the template use the updated questions.

Custom templates are organisation-scoped. To make a template available platform-wide, a superuser can promote it to a system template from Admin > Templates.

Templates are organised by category: Framework (ISM, CPS 234, SOC 2, etc.), Info Security, Privacy, BCP, Financial, ESG, AI Governance, and AI Vendor Risk Assessment. Use the category filter to find templates relevant to your vendor risk profile.

Seven domain templates complement the framework-specific templates: Information Security (general-purpose), Privacy & Data Protection (APPs, NDB), BCP & Operational Resilience (RTO/RPO, DR), Financial & Supply Chain Risk (insurance, concentration), ESG & Modern Slavery (Modern Slavery Act 2018), AI Governance (model risk, bias, explainability), and AI Vendor Risk Assessment (structured 18-question questionnaire covering model risk, data governance, bias, security, transparency, and compliance for AI-powered vendors).

When creating an assessment for a specific vendor, ChainShield recommends templates based on the vendor’s regulatory scope, data sensitivity, business criticality, AI usage, and material service provider status. Look for the "Recommended" badge.

System templates are read-only. Click "Clone" to create your own editable copy. Add, remove, or modify questions to match your specific requirements. Your cloned templates appear in the "My Templates" section.

Start with the Information Security Assessment for a general-purpose review. Add the Privacy & Data Protection Assessment if the vendor handles PII. For APRA-regulated clients, also use the CPS 234 template. The recommendation engine will suggest the right templates based on vendor context.

Framework templates (ISM, CPS 234, SOC 2, etc.) are aligned to specific regulatory standards with questions referencing control IDs. Domain templates (Info Security, Privacy, BCP, etc.) take a broader, risk-domain approach that is not tied to a single regulation. Use framework templates for compliance, domain templates for risk coverage.

Use the AI Vendor Risk Assessment for any vendor that develops, deploys, or integrates AI/ML systems into their services. It covers 6 categories (Model Risk, Data Governance, Bias & Fairness, Security, Transparency, Compliance) with 18 questions. Responses automatically generate findings mapped to app_api_security (technical AI/product security, formerly CYBER_05) and responsible_ai (Responsible AI Governance, formerly COMPL_06) controls. This is an advisory assessment aligned with the National AI Plan voluntary ethics framework — it does not imply a regulatory mandate.

The AI Governance template is a broader governance maturity assessment. The AI Vendor Risk Assessment is specifically structured for vendor self-declaration, with 18 questions that directly generate OPEN or PASS findings for risk scoring. Use the AI Governance template for internal governance reviews; use the AI Vendor Risk Assessment when sending a questionnaire to an AI vendor.

The Summary tab shows the asset's risk score, exposure score, confidence level, discovery source, and key metadata such as geolocation, confirmation status, and recent scanning dates. A 30-day risk trend sparkline shows how the parent vendor's risk has changed over time.

Lists all security findings linked to this asset, sorted by severity. Click any finding to view its full detail panel. Findings are loaded in batches of 50 — use the "Load more" button to fetch additional results if the asset has many findings.

Lists CVEs detected on this specific asset, sourced from vendor_vulnerabilities records created by the scan pipeline. Each row shows the CVE ID (linked to the full CVE detail page), severity (CRITICAL/HIGH/MEDIUM/LOW from CVSS score), EPSS score, host, and first/last seen dates. A KEV badge appears for CVEs that are actively exploited in the wild. Suppressed CVEs (accepted or resolved by your organisation) are hidden by default. The tab count badge shows the total non-suppressed CVE count. Large vulnerability lists paginate server-side with 50 results per page - use the pagination controls to load additional results.

Shows parent and child assets connected via relationship types (RESOLVES_TO, SUBDOMAIN_OF, HOSTED_ON, etc.). Click any related asset to navigate to its detail page. This helps you trace infrastructure dependencies.

Displays open ports and services discovered on this asset via Censys, Shodan, or scan pipeline probes. High-risk ports (RDP 3389, SMB 445, Telnet 23, etc.) are highlighted in red.

Shows TLS certificate details: issuer, subject, validity dates, protocol version, cipher suite, key strength, signature algorithm, and Subject Alternative Names (SANs). Certificates are sourced from bbot scans, SSL Labs assessments, or active TLS probes on port 443 when no passive data is available. Expiry warnings appear when the certificate is expired or expiring within 30 days.

Displays compliance mappings for this asset against Australian regulatory frameworks (ISM, CPS 234, Privacy Act, SOCI Act). Each framework section lists mapped control IDs with titles and applicability status.

Shows AI-generated analysis: AI summary, risk context narrative, exposure rating (CRITICAL/HIGH/MEDIUM/LOW), and confidence score. Use the "Re-analyze" button to trigger a fresh AI enrichment pass. Only visible when AI analysis features are enabled.

Risk Score (0-100) reflects the severity-weighted finding impact on this asset. Exposure Score measures how visible and accessible the asset is. Both use standard risk colours: green (0-30), amber (31-50), orange (51-70), red (71-100). A lower score is better.

Open the asset detail page and click the Vulnerabilities tab. It lists all CVEs that the scan pipeline detected on this asset, with severity (derived from CVSS score), EPSS exploitation probability, KEV badge for actively exploited CVEs, and first/last seen timestamps. Click any CVE ID to open its full detail page. If your organisation has suppressed a CVE (Accepted or Resolved via the vulnerability suppression workflow), it will be hidden from this tab by default.

Use the Related Assets tab to see all parent and child relationships. Click any related asset to open its detail page. You can also navigate from the modal view by clicking "Open full page" in the header.

It triggers an AI enrichment pass for this specific asset, refreshing the AI summary, risk context, exposure rating, and confidence score. The analysis runs asynchronously - refresh the page after a few moments to see updated results.

Risk Score (0-100) reflects the severity-weighted impact of findings linked to this asset. Exposure Score measures how visible and accessible the asset is from the internet - factoring in open ports, public accessibility, and hosting location. An asset can have high exposure (publicly accessible) but low risk (no findings), or vice versa.

Assets are discovered through the scan pipeline: The discovery engine runs DNS enumeration, subdomain brute-forcing, certificate transparency log searches, and WHOIS lookups. Enrichment adds Shodan/Censys port data, TLS certificate details, and geolocation. AI agents correlate discovered assets with vendor metadata for confirmation.

Certifications with an expiry date are automatically marked EXPIRED the day after the expiry date passes. A daily cron job runs this check at 03:00 UTC. Update the certification's expiry date to a future date and change the status back to VERIFIED to restore it. This automatic expiry helps you stay aware of certifications that need renewal or replacement.

The Agent State panel (visible on the Operations tab for superusers) shows the status of the tracked pipeline identities for the latest scan, including the 7 domain agents and utility/review/enrichment workers. If you see 'Partial coverage' (e.g. 'cybersecurity last succeeded 12 days ago'), it means that identity has not run recently, indicating a data gap. For example, a stale cybersecurity agent may miss new vulnerabilities. Use the Retry button where available to force that identity to run immediately, or check the error message to diagnose rate-limiting or API issues.

The risk narrative is regenerated automatically when new scan results represent a material change: a new CRITICAL or HIGH finding, total findings grew/shrank >20%, or a new type of finding was detected. When regeneration happens, a banner appears with the reason (e.g. '4 new findings added'). The new narrative reflects the current risk landscape. If you made manual edits to the narrative, they are preserved; regeneration only happens for machine-generated narratives.

Incidents are public breach and outage events discovered through news and breach databases (HaveIBeenPwned, security news). They appear on the Incidents tab and can amplify reputational risk by up to 30 points depending on severity. Critical incidents (large breaches, ransomware) add more uplift than minor incidents. Incidents linked to findings you've already recorded are marked to avoid double-counting. Use incidents as context when assessing reputational and operational resilience risk.

Nodes represent discovered assets, colour-coded by type and sized by risk score — higher risk assets appear larger. Edges show relationships like SUBDOMAIN_OF, RESOLVES_TO, HOSTED_ON, and SERVES. High-risk nodes (60+) display a dashed halo to draw attention.

Click legend items to filter by asset type. Use the risk level dropdown to show only nodes above a threshold (Critical 80+, High 60+, Medium 30+). Toggle "Hide inactive" to remove RETIRED/RESOLVED assets. Filters combine — e.g., show only high-risk IPs.

Drag any node to reposition it; the graph physics will settle around the new position. Click a node to see its details including risk score, connection count, and linked findings. Use zoom controls or fullscreen mode to explore complex asset hierarchies.

Node size is proportional to the asset's risk score. Assets with more or higher-severity findings appear larger, making them visually prominent. This helps you quickly identify the riskiest parts of the attack surface.

Use fullscreen mode and your browser's screenshot capability. The graph is interactive and dynamically rendered, so a static export is not currently available. For reporting, the Assets tab provides tabular export in CSV format.

Sort findings by severity, type, or date detected. Filter by control area to focus on specific risk domains (cybersecurity, compliance, operational resilience, etc.).

Each finding shows the evidence that triggered it (e.g. DNS records, TLS certificate details, open ports). Review the evidence to understand what was detected and verify it is accurate.

Your profile shows your email, organisation name, and contact details as registered with ChainShield. This information is used for portal communications and assessment delivery.

To update any information, contact the organisation that invited you. They can make changes to your vendor record in their ChainShield account.

Add each test with its type (Tabletop, Simulation, Full Exercise, Component), result (Pass, Partial, Fail), date, and notes. Record both the target and achieved RTO/RPO values so ChainShield can track objective attainment.

Recovery Time Objective (RTO) is the maximum acceptable downtime. Recovery Point Objective (RPO) is the maximum acceptable data loss period. Bars are colour-coded: green when objectives are met, red when missed. Consistent misses indicate the vendor needs to improve their DR capability.

For CPS 230 Material Service Providers, schedule BCP tests at least annually. The next test due date shows an overdue warning when past due. The latest BCP test result feeds into the vendor health score (5% weight) and the CPS 230 Material Service Provider Register export.

BCP test records contribute 5% of the vendor health score. With no records, the health score treats BCP readiness as zero. The CPS 230 MSP Register export shows "Not assessed" for BCP compliance, and regulatory reviewers treat this as evidence of an untested business continuity arrangement. Add records for any tests already conducted, even retrospectively, to populate the health score and MSP Register correctly.

APRA expects a range of testing: Tabletop (discussion-based walkthrough), Simulation (scenario exercise without real failover), Full Exercise (actual failover to backup systems), and Component (testing a single element like backup restore). Full exercises provide the strongest assurance.

The latest BCP test result replaces the default "Not assessed" status in the CPS 230 Material Service Provider Register export. Include test history in your annual board reporting on operational resilience.

Your plan determines how many vendors you can monitor: Free (2 vendors, $0/month), Starter (10 vendors, $490/month), Essentials (25 vendors, $975/month), Pro (50 vendors, $1,450/month), or Enterprise (custom pricing). Each plan includes a certain number of vendors with per-vendor overage fees for extras. Volume discounts get better at higher tiers.

ChainShield offers five self-serve pricing tiers tailored to different organisational needs. Free tier includes essential vendor monitoring with a 2-vendor limit. Starter, Essentials, and Pro tiers include increasing vendor counts with lower per-vendor overage rates as you move up. Enterprise tier offers unlimited vendors and custom terms for large portfolios. Pricing is in AUD, incl. GST.

If your organisation exceeds the included vendor count in your plan, additional vendors are billed at the per-vendor overage rate for your tier. For example, if you are on Starter (10 included at $49/extra), adding 3 more vendors costs an extra $147/month. Overage charges appear on your next invoice.

New organisations receive a 14-day free trial granting Starter-tier features (10 vendors) at no cost. The trial is automatically activated on signup. After the trial expires, the organisation reverts to the Free plan (2 vendors) unless you upgrade. Trial status appears in the banner at the top of this page with the expiry date.

Click the "Manage subscription" button to access the Stripe Customer Portal, where you can update payment methods, view invoices, and manage billing details. The portal is hosted securely by Stripe and is the only place to modify active subscription settings.

Click the upgrade button on your desired plan tier card. You will be directed to Stripe Checkout where you can enter payment details. After successful payment, your new plan activates immediately and you can begin monitoring more vendors. Your previous plan is automatically cancelled.

If your payment method fails, ChainShield sends you a dunning notice. You have 7 days to update your payment method in the Customer Portal to avoid read-only restrictions on your account. After day 7, your account moves to read-only mode -- you can view data but cannot add vendors or create new findings. Update your payment method before this deadline to restore full access.

Some organisations have negotiated custom pricing (e.g., volume discount, flat reduction). If your organisation has a negotiated rate, a banner appears here showing the discount you receive. Custom pricing is managed by your MSP administrator and cannot be changed directly by your organisation.

If auto-tier is still enabled on your account, ChainShield automatically adjusts your plan based on vendor count and regulatory context. Once you upgrade to a paid Stripe subscription, auto-tier is disabled and your plan is frozen at the tier you selected until you manually change it. Manual control gives you predictable costs without surprise upgrades.

ChainShield pricing depends on your vendor count. Free tier is $0/month for 2 vendors. Starter is $490/month for 10 vendors. Essentials is $975/month for 25 vendors. Pro is $1,450/month for 50 vendors. Enterprise plans are custom. Additional vendors beyond your included count are billed at the per-vendor overage rate for your tier. New organisations receive a 14-day free trial at Starter-tier features (10 vendors).

Your 14-day free trial grants Starter-tier features (10 vendors) at no cost. When the trial expires, your organisation automatically reverts to the Free plan (2 vendors, $0/month). You can upgrade to any paid tier at any time by clicking the upgrade button on the plan you want.

Yes. You can downgrade to a lower tier from the Manage subscription portal. If you have more vendors than your new plan allows, you must either archive vendors or accept overage charges. A warning dialog shows your estimated overage cost before you confirm the downgrade.

Yes. If your vendor count exceeds the included amount in your plan, each additional vendor is charged at the per-vendor overage rate for your tier. For Starter, that is $49 per vendor per month. For Essentials, $39 per vendor per month. Overage is calculated monthly and appears on your invoice.

Click the "Manage subscription" button on this page to open the Stripe Customer Portal. In the portal, go to Payment Methods and add or update your card. Changes take effect immediately for the next billing cycle.

ChainShield sends you an email notification and displays a dunning notice on this page. You have 7 days to update your payment method in the Customer Portal. If unpaid after 7 days, your account moves to read-only mode (you can view data but cannot add vendors or modify findings). After 14 days, your subscription is cancelled. Update your payment method to restore full access.

No. ChainShield operates on a month-to-month basis. You can cancel your subscription or downgrade at any time through the Manage subscription portal. Cancellation takes effect at the end of your current billing cycle.

Some organisations receive custom pricing negotiated with their MSP, such as a volume discount or flat reduction. If you have a negotiated rate, a banner on this page shows your discount. Negotiated rates are managed by your MSP administrator and cannot be changed directly by your organisation.

ChainShield invoicing is in Australian dollars (AUD), incl. GST. GST is calculated automatically by Stripe Tax at checkout. Payments are processed securely through Stripe in your local currency.

ChainShield MSP pricing is based on client count with per-vendor economics that scale. Add SCRM to your service catalogue without building tooling in-house.

The Concentration Score (0–10,000) measures how evenly your dependencies are spread. Below 1,500 means well-diversified — no single provider dominates. Above 2,500 means high concentration that could create resilience risks if that provider fails. Focus on reducing scores above 2,500 by diversifying providers for critical services.

When too many vendors or assets are in one region, a local outage or regulatory change can hit your whole portfolio. Review this dimension and ensure critical services have alternatives in different geographies, especially if you are APRA-regulated under CPS 230.

If most of your vendors run on a single cloud provider (AWS, Azure, GCP), a major outage there could take down multiple services at once. Identify which critical vendors share the same provider and ensure you have contingency plans or multi-cloud alternatives for essential services.

When too many vendors operate in the same service area, losing one affects your ability to switch because alternatives are limited. Review categories with high concentration and identify backup providers for critical services so you are not locked in.

Review the remediation guidance shown for each dimension with a MEDIUM or higher risk rating. Common actions include: diversifying hosting across cloud providers, ensuring vendors in critical categories have identified alternatives, and validating that vendor disaster recovery plans account for regional outages.

ChainShield automatically creates findings when concentration exceeds safe thresholds. Cloud concentration maps to operational resilience controls, geographic concentration maps to geopolitical controls, and service category concentration maps to financial/supply chain controls. These findings flow into your risk scores, so addressing concentration directly improves your composite score.

Geographic data comes from the vendor_locations table (normalized from physical_locations) and asset geo-location metadata populated during scans. Cloud provider data is derived from asset ASN information and hosting metadata. Service categories use the vendor industry field.

Concentration risk is calculated on-demand each time you view this page, using the latest vendor and asset data. Run regular scans to keep the underlying data current.

Yes. Auto-generated concentration findings feed into critical_operations, data_residency, and concentration_risk control scores, which flow into the Operational Resilience, Geopolitical & Sovereign, and Financial & Supply Chain risk domains respectively. This means portfolio-level concentration now directly impacts per-org composite risk scores.

Invite and password-recovery emails deliver a login token as part of the link you clicked. This page reads that token, establishes your session, and — for a brand-new invite — sends you on to set your password; for a magic-link sign-in, it sends you straight to your destination. This normally takes under a second.

If this page does not redirect within a few seconds, the invite link has likely expired or was already used. Return to the sign-in page and use "Forgot password?" if you already have an account, or ask whoever invited you to resend the invitation if your account has not been set up yet.

Tell us whether you are enquiring as an organisation (managing your own vendor risk), an MSP (delivering SCRM to clients), or other. This helps us route your inquiry to the right team.

Provide your contact details, organisation name, approximate number of vendors, and a description of what you need. The more context you provide, the faster we can help.

We aim to respond to all inquiries within 1-2 business days. For urgent issues, call us or check the dashboard for support contact details.

Cookies are small text files stored on your device by your browser. ChainShield uses essential cookies only, which are necessary for the platform to function (e.g. to keep you signed in). We do not use analytics, advertising, or tracking cookies.

Session cookies are deleted when you close your browser. Persistent cookies remain for a set duration (e.g. refresh tokens). All cookies are HttpOnly and Secure (encrypted in transit) to protect your session.

Your browser settings allow you to delete or block cookies. Disabling essential cookies will prevent you from signing in. For more control, refer to your browser's privacy settings.

You will need a valid email address and a strong password (at least 8 characters, with uppercase, lowercase, and a number). If your organisation has SAML SSO set up, you can sign up using your company credentials.

After creating your account, you will be guided through setup: creating your organisation, confirming your email, and inviting team members. The process takes about 5 minutes.

If you already have a ChainShield account, sign in instead. If you forgot your password, use the password reset link on the sign-in page.

If you received an invitation email (to join an organisation, claim an MSP, or access the vendor portal), follow the link in that email instead of signing up here. Invitations create your account through a secure set-password email so only the invited mailbox can activate it — this page only creates a brand-new free organisation.

Rather than starting blank, clone an existing system template and customise it. System templates cover regulatory frameworks (ISM, CPS 234, SOC 2, SOCI Act, NDB), compliance domains (Information Security, Privacy, BCP, Financial Risk, ESG/Modern Slavery), and AI governance.

Available question types: short text, long text, yes/no toggle, multiple choice, rating scale (1-5 or custom), and file upload. Use file upload for evidence collection (certifications, SBOMs, audit reports).

Group related questions into sections (e.g. "Access Control", "Incident Response"). Sections provide context for vendors and make long questionnaires less overwhelming. Drag to reorder sections and questions.

Save your template as a draft before sending. You can edit it as many times as you need. Once you send an assessment to a vendor, the template is locked (vendors are completing that version).

Yes. Organisation admins can modify their regulatory frameworks in their own Settings page. MSP-configured defaults serve as the starting point. Per-vendor regulatory scope overrides are also available.

Select the customer, update the plan tier and vendor limit, then save. Changes take effect immediately. The customer sees their updated plan details in Settings > Billing.

Not currently. Customer settings must be updated individually. For large MSPs managing many customers, use the API for programmatic updates.

CVSS (Severity): base score from NVD, ranges 0–10. EPSS (Exploitation Probability): likelihood this CVE will be exploited in the wild, ranges 0–100%. A medium-severity CVE with high EPSS (actively exploited) is often higher priority than a critical CVE with zero EPSS.

The page shows which vendors in your organisation have this CVE as an open finding. Click on a vendor to see the specific finding (which technology component, when it was detected, remediation status).

Remediation guidance is sourced from NVD and enriched by ChainShield AI. It includes recommended patch versions, workarounds, and general mitigation strategies. Always verify guidance against your vendor's official security advisories.

CISA KEV (Known Exploited Vulnerabilities) indicates this CVE has been actively exploited by threat actors. CVEs with KEV status require urgent attention — prioritise these above other CVEs.

EPSS scores are updated daily as new threat intelligence is collected. A CVE that had low EPSS yesterday may have high EPSS today if threat actors begin exploiting it. Check this page regularly for high-severity CVEs.

This CVE has been detected in the public internet but does not affect any of your vendors (based on technology fingerprinting). You may want to monitor this CVE if it affects technologies your vendors use or plan to use.

If you believe a finding is incorrect (e.g. vendor has already patched, or the component is not actually used), navigate to the finding and mark it as ACCEPTED (compensating control) or RESOLVED (patched). This will update your vendor's risk score.

ChainShield stores data in Australian-hosted infrastructure. This page shows where your organisation's data resides and any cross-border data flow considerations relevant to ISM data sovereignty requirements.

ISM and PSPF require Australian Government data to remain within AU sovereign infrastructure. CPS 234 requires APRA-regulated entities to manage information security risks including those arising from offshore data storage. Review this page to verify compliance.

Your vendors' data sovereignty posture is tracked on the Assets page — filter by hosting location to identify non-AU sovereign assets. This page focuses on where ChainShield itself stores your organisational data.

ChainShield uses Supabase (PostgreSQL) with Australian hosting. Scan results, findings, and assessments are stored in the primary database. File uploads (SBOMs, evidence) are stored in Supabase Storage with server-side encryption.

Currently, all data is stored in the primary Australian region. Multi-region support is on the roadmap. Contact support if you have specific data residency requirements.

AI analysis is routed through the configured LiteLLM proxy using ChainShield model-group aliases. Data sent for analysis includes finding descriptions and vendor metadata — no credentials or personal information. Review the LiteLLM proxy and underlying model-provider data handling policies for processing location details.

Data Access: receive a copy of all personal data we hold about you. Data Erasure: request deletion of your personal data. Data Portability: request your data in a machine-readable format. Data Rectification: request correction of inaccurate data.

Submit your request with your email address and preferred request type. We will respond within 30 calendar days per the Australian Privacy Act. Complex requests may require additional time. You will receive communication at the email address provided.

We may need to verify your identity before processing your request. If you are requesting data on behalf of another person, you must provide written authority from that person.

Update the vendor name, primary domain, industry sector, description, contact information, and classification. Domain changes trigger asset re-discovery on the next scan. All changes are audit-logged.

Changing the primary domain updates the scan target. Existing assets linked to the old domain are retained. Run a new scan after changing the domain to discover assets on the new domain.

Set the vendor's industry sector, trading name, and description. The industry sector affects which risk domain weights are prioritised for this vendor. Trading name and ABN are populated automatically by the ABR lookup agent when available.

Add primary and secondary contact details for the vendor. These are used for assessment invitations, remediation requests, and incident communications via the vendor portal.

No. The vendor ID is a UUID - all historical data (findings, assets, scans, assessments) is linked by ID, not name. Name changes only affect the display label.

Vendor merging is not currently supported from the UI. If you have duplicate vendor records, archive one and keep the other active. Contact support for data-level merge if needed.

Excluded vendors continue to be scanned and monitored, but their findings are not counted towards your organisation's composite risk score. This allows you to monitor vendors transitioning to offboarding, vendors undergoing dispute resolution, or vendors where risk has been formally accepted without that risk inflating your organisation's overall posture.

Exclusion requires an authorised organisational role such as Owner, Admin, Security, or Compliance. This prevents accidental removal of vendors from risk calculations and ensures governance oversight.

Go to the vendor detail page and select the "Exclude from risk posture" option in the Risk Context section. Provide a reason (offboarding, remediation hold, risk accepted, other) and optional notes explaining the exclusion. The vendor moves to the Excluded list immediately.

Findings for excluded vendors continue to be discovered and displayed on the vendor detail page. However, they do not factor into `organisation_vendors.risk_score`. This means your risk dashboard reflects your actual operational risk (excluding vendors you've consciously de-scoped) while still maintaining visibility into their status.

Click "Reinstate" on the vendor card in the Excluded list. The vendor returns to normal risk scoring immediately and its open findings are included in the next risk score recalculation.

Each exclusion has a review date. Quarterly reviews are recommended to ensure vendors are not left excluded indefinitely. Overdue exclusion reviews are highlighted in the Excluded list and on your dashboard "Needs Attention" card.

Termination is a lifecycle stage on the vendor detail page indicating the vendor relationship has ended. Exclusion temporarily removes a vendor from risk scoring while keeping them visible and monitored. A terminated vendor can be excluded, but exclusion does not terminate the relationship.

Excluded vendors are still scanned and monitored. Critical findings will still appear in your dashboard's "Needs Attention" card, but they will not contribute to the organisation's risk score. This ensures you remain aware of issues even when they don't affect your compliance posture.

Exclusions should be reviewed at least quarterly. If a vendor is excluded for more than 90 days without a documented review, your dashboard will prompt you to either reinstate or formally close the relationship. This prevents "vendor drift" where excluded vendors are forgotten.

Your risk reports show two scores: Operational Risk (including all active vendors) and Compliant Risk Posture (excluding blocked/excluded vendors). This transparency shows auditors that you've consciously managed your risk exposure.

Yes, but this is unusual. Exclusion is for vendors where risk is accepted or temporarily removed from operations. If the vendor has an active contract, consider whether termination might be more appropriate. Contact your Owner, Admin, Security, or Compliance lead if unsure.

A vendor may be stuck at "scan not started" because its domain could not be resolved. Check the vendor detail page for a "Domain unreachable" status with an error message. This typically means the domain is misspelled, expired, or never existed. Click "Edit domain" in the inline alert, correct the domain name, and click "Re-scan". ChainShield will attempt domain resolution again, and if it succeeds, the normal scan process continues. If the domain is correct, check with your IT team to ensure the domain exists and is not blocked by network filters.

The Exit Readiness Score (0–100%) is calculated from 7 factors: plan is active (20%), alternative vendors identified (15%), data deletion documented (15%), knowledge transfer planned (15%), step-in rights documented (10%), plan tested within 12 months (15%), and contract exit clauses present (10%).

A complete exit plan covers: transition timeline, data return and deletion procedures, knowledge transfer plan, step-in rights, alternative vendor identification, and test history. Material service providers without an ACTIVE exit plan are flagged in the MSP Register export.

Test the exit plan annually and update it whenever the vendor relationship changes materially (new services, data types, or regulatory designations). Record test results including lessons learned and plan updates.

The vendor health score includes a 5% weight for exit plan readiness. With no plan, that contribution is zero and the MSP Register export shows "No plan" for this vendor. APRA supervisors reviewing CPS 230 submissions will flag material service providers without documented exit strategies. Create the plan with at minimum a transition period, alternative vendors, and data deletion method to satisfy the minimum requirement.

Under CPS 230, APRA-regulated entities must have exit plans for all material service providers. Best practice extends this to any vendor handling sensitive data or providing critical services, even if not formally designated as material.

Step-in rights are contractual provisions that allow you (or a regulator) to assume operational control of the vendor's service delivery in extreme circumstances (e.g., vendor insolvency). Document whether these rights exist and under what conditions they can be exercised.

The finding detail page presents a conclusion-first evidence trail: Conclusion (verdict + status), Evidence Summary (what was found), Reasoning (why it is a risk, collapsed by default), Limitations (what could not be verified), Business Impact, Vendor Communication (copy-ready remediation ask), Sources, and Discovery Trail (probe log for EVIDENCE_GAP findings). Header chrome, asset, compliance, org status, and comments remain below the trail.

When a finding status is EVIDENCE_GAP, the Reasoning section auto-expands so the gap explanation is immediately visible. The Discovery Trail shows every probe that ran before the gap was declared — DNS probes, TLS checks, HTTP requests — and what each returned (ok, no_result, blocked, timeout). A long list of blocked or no_result entries suggests the vendor actively restricts scanning; contact them directly to verify.

For CVE findings, severity is determined by EPSS (Exploit Prediction Scoring System) first, which predicts real-world exploitation probability in the next 30 days. EPSS thresholds: 70%+ = CRITICAL, 30-70% = HIGH, 10-30% = MEDIUM, <10% = LOW. CVSS is used as fallback only when EPSS data is unavailable.

Use the status workflow: OPEN (new) -> IN_PROGRESS (remediation underway) -> PENDING_REVIEW (awaiting approval) -> RESOLVED (confirmed fixed). You can also mark as ACCEPTED (risk accepted, not fixing) or FALSE_POSITIVE (not a real issue). Status changes are audit-logged.

The compliance section shows which Australian regulatory controls this finding affects — ISM, CPS 234, CPS 230, Privacy Act, SOCI, NDB, and Cyber Security Act 2024. Each mapping links to the specific control ID and helps prioritise remediation based on regulatory obligations.

The Tool Evidence section displays the raw structured data from scan agents that backs this finding. This includes DNS records, HTTP headers, port scan results, TLS certificate details, and more. Data is shown as tables (for lists like DNS records) or key-value pairs (for headers). Use the "Show Raw JSON" toggle to inspect the full JSONB payload. All content is rendered as text — no HTML is executed.

The Sources section displays all reference links for this finding in a single unified view. This includes the detection tool, crawled source pages, and CISA KEV exploitation references — all stored in a single structured sources field. Click any link to verify the evidence yourself.

Use the "Create Task" button in the Remediation section to track remediation work. Tasks have a priority, optional assignee, and due date. Status follows OPEN -> IN_PROGRESS -> COMPLETED -> VERIFIED. Overdue tasks are flagged red. Tasks are scoped to your organisation.

AI analysis results are consolidated in the ai_analysis JSONB object on each finding. This includes the concise description, contextual risk assessment, and a confidence indicator reflecting how much scan data was available. Remediation guidance, steps, and complexity are stored in a separate remediation JSONB object. Review AI guidance critically — it is generated from scan data and may need context from your specific environment.

Some findings record an absence — for example "no public security disclosure policy". The "What was attempted" panel lists the sources that were probed before the gap was declared. If a source returned 404, was rate-limited, or was blocked, it appears here so you can verify the gap before remediating. A long list of "no_result" or "blocked" entries suggests the vendor actively restricts automated scanning — contact them directly. An empty panel on an EVIDENCE_GAP finding means the gap was raised by a deterministic enrichment check (not an LLM agent) that did not record individual probes.

If Jira or ServiceNow is configured, click "Create Ticket" to push this finding to your ticketing system. The ticket includes severity, control mapping, vendor name, description, remediation guidance, and a link back to ChainShield.

Click "Create Incident" to open the incident reporter pre-populated with the finding's title, severity, vendor, and description. The modal also shows regulatory framework checkboxes based on your organisation's configured frameworks. Frameworks auto-detected from the finding's metadata (NDB trigger, compliance mappings, severity) are pre-checked, but you can add or remove any framework before creating the incident. Each checked framework creates a regulatory notification record with the correct deadline.

Each finding maps to one of 30 current controls via control_id. Controls are grouped into 7 scoring domains (Cybersecurity, Operational Resilience, Compliance & Regulatory, Privacy & Data Protection, Financial & Supply Chain, Reputational, Geopolitical & Sovereign). Each control maps to specific regulatory frameworks, driving automatic compliance mapping.

Evidence is structured data (JSONB with summary, data, tool, and collected_at fields) from scan agents that produced the finding. It can include DNS records, HTTP headers, port scan results, TLS certificate details, WHOIS data, and more. Evidence is displayed as structured tables and key-value cards, with a raw JSON toggle for full inspection.

Source URLs show which specific web pages an AI agent crawled to produce this finding. Click through to verify the evidence yourself. All source links are consolidated in the Sources section alongside the primary source URL and any CISA KEV exploitation references.

If you believe a finding is incorrect, mark it as FALSE_POSITIVE with a note explaining why. Organisation-level false positive status only affects your organisation. Superusers can apply SYSTEM_FALSE_POSITIVE to hide it platform-wide.

The risk score (0-100) combines three factors: severity (base points from CVSS or control criticality), likelihood (how likely exploitation is, from EPSS data or evidence quality), and context bonuses (internet-facing exposure, end-of-life software, high-weight controls). A CRITICAL CVE with high EPSS on a public-facing server scores much higher than the same CVE on an internal system with low exploitation probability. The risk factors breakdown on each finding shows exactly how the score was calculated.

Click the "Create Incident" button in the action bar on the finding detail page. The incident form is pre-populated with the finding's title, severity, vendor, and description. You can select which regulatory frameworks apply — frameworks detected from the finding's metadata are pre-checked. Each selected framework creates a regulatory notification with the correct deadline. The finding is automatically linked to the incident.

Scan status 'Completed with Errors' means some asset or finding data failed to write during the scan ingest phase, but other data succeeded. This can happen due to transient database issues or network interruptions. The risk score is calculated from whatever data was successfully written, so a partial scan may show a lower risk score than a complete scan. If this status persists across multiple scans for the same vendor, contact support. Check the audit log for details on which data failed.

This message appears when linked assets exist but could not be loaded due to access restrictions. This is expected cross-tenant behaviour - the linked assets belong to a vendor you do not have permission to view, or they were removed. If you believe this is incorrect, contact your MSP administrator to verify your org has access to the vendor in question.

The finding presents a Conclusion (one-sentence verdict), Evidence Summary (what the scan observed), Reasoning (why this is a risk), Limitations (what could not be verified), Business Impact, and a Vendor Communication block with the exact wording your security contact needs. Use the "Copy to clipboard" button to paste the vendor communication into your email or ticketing system.

A status of "Could not verify" means the scan could not confirm or refute the finding with external data. The Reasoning section expands automatically to show the gap explanation, and the Discovery Trail lists every probe that was attempted. If the information exists, point the organisation to the public URL and they can update the finding status.

Use the Respond to Finding form below the evidence trail to acknowledge, mark in-progress, confirm remediation, or dispute the finding. Responses are visible to the organisation. For disputes, include a clear rationale — for example, a compensating control that makes the finding not applicable to your environment.

The triage queue shows all OPEN and PENDING_REVIEW findings for vendors linked to your organisation. Findings are sorted by severity (CRITICAL first) then by age (oldest first within the same severity). This ensures the highest-risk, longest-outstanding issues surface at the top.

Acknowledge: marks the finding as IN_PROGRESS (you have seen it and are tracking it). False Positive: marks the finding as not applicable to your organisation. Resolve: marks the finding as remediated. All actions update the per-organisation status only and do not affect other organisations viewing the same vendor.

Select individual findings with checkboxes, or use the vendor-level "Acknowledge all" and "Mark INFO reviewed" buttons to process multiple findings at once. Selected findings can be bulk-actioned using the toolbar that appears above the list.

Use the Filters panel to narrow by severity, vendor, or date range. Results are paginated at 50 per page. Severity summary badges at the top show counts per level and can be clicked to filter.

For each sub-contractor your vendor relies on, record their service category (e.g., cloud hosting, payment processing), data access level, and geographic location. Mark material fourth parties so they appear in CPS 230 reports — missing entries create blind spots in your supply chain risk view.

If the same sub-contractor (e.g., AWS, Cloudflare) appears across multiple vendors, it becomes a single point of failure. Check the Compliance dashboard for concentration warnings — sub-contractors used by more than 50% of your critical vendors need a contingency plan.

APRA CPS 230 requires a register of material sub-contractors with risk assessments and contractual controls. Build and maintain that register here for each vendor to meet your regulatory obligations and prepare for APRA review.

A material fourth party is one whose failure would significantly disrupt the vendor's ability to deliver services to your organisation. Under CPS 230, you must identify and monitor material fourth parties. Mark them using the "Material" toggle.

Fourth-party entries feed into the Operational Resilience domain. Vendors with many material fourth parties, unclear data access controls, or concentration in a single jurisdiction receive higher scores in this domain.

Questionnaire responses are converted to findings via rule-based mapping. Answers indicating compliance (e.g. "Yes, we have a BCP") create PASS findings that confirm the control is met. Answers indicating non-compliance create LOW-severity EVIDENCE_GAP findings. Self-attested PASS findings reduce open gaps but do NOT override external evidence (e.g. verified certifications, scan findings). If a questionnaire says "Yes, we have ISO 27001" but your scan finds unpatched vulnerabilities, the external findings take precedence in risk scoring.

Questionnaire responses are self-attestations — the vendor says they meet a control, but it's not independently verified. Scan findings and certifications prove compliance through external observation. ChainShield scores self-attested findings with lower confidence than externally-discovered evidence, so external evidence always wins when both exist for the same control.

Not directly. A questionnaire PASS finding downgrades the severity of a matching EVIDENCE_GAP (MEDIUM → LOW) rather than closing it. External evidence (from a later scan, certification, or audit) is still required to fully close the gap. This prevents vendors from "ticking boxes" without backing evidence.

Activate a playbook when a vendor reports a data breach, when a critical CVE is disclosed affecting a vendor’s technology stack, or when monitoring detects a significant change in a vendor’s risk posture. Early activation ensures consistent, auditable response.

Default playbooks cover common scenarios (data breach, ransomware, supply chain compromise). Duplicate and tailor them to your organisation’s regulatory obligations and internal processes.

Playbooks include regulatory notification checklists. For data breaches: NDB (30 days), CPS 234 (72 hours), Cyber Security Act (72 hours), CPS 230 (10 days), SOCI (30 days). Each step links to the incident notification tracker.

Four default playbooks: Data Breach Response (NDB-aligned), Ransomware Incident (containment + recovery), Supply Chain Compromise (vendor cascade), and Critical Vulnerability Disclosure (CVE triage). Each includes steps for detection, containment, eradication, recovery, and lessons learned.

Yes. Organisation admins can duplicate any existing playbook and customise the steps, stakeholders, and notification rules. Custom playbooks appear alongside default ones in the playbook library.

When creating an incident, you can attach a playbook. The incident timeline then shows each playbook step as a checklist item. Completing steps on the incident automatically updates the playbook progress tracker.

Three categories: Notifications (Slack, Teams, generic webhooks for real-time alerts), Ticketing (Jira Cloud, ServiceNow for creating issues from findings), and SIEM (Splunk HEC, Microsoft Sentinel, Elastic for security event forwarding). Configure one or more to fit your workflow.

Create a webhook endpoint with a descriptive name, URL, and shared secret. Choose the event types to subscribe to: finding.created, vendor.risk_changed, assessment.completed, scan.completed, incident.created, vendor.added. Payloads are signed with HMAC-SHA256 using your shared secret.

Create a Slack Incoming Webhook URL in your Slack workspace settings, then paste it here. ChainShield sends formatted message cards with finding severity, vendor name, and direct links. Choose which events trigger Slack notifications.

Connect to Jira Cloud with your instance URL, email, and API token. Select a default project key. Finding severity maps to Jira priority, and control mapping is included as a label. Use "Test Connection" to verify before saving.

Only organisation admins with the "Manage Integrations" permission can create, edit, or delete webhooks. URLs are masked in the audit log to prevent accidental exposure of internal endpoints or authentication parameters in shared logs.

Failed webhook deliveries are retried automatically up to 3 times with exponential backoff. Check the delivery log to see success/failure history. Common failures: endpoint unreachable, non-2xx response, or HMAC validation failure on the receiving end.

After creating a webhook, use the "Send Test" button to deliver a sample payload. Check your endpoint for the test event. If it fails, verify the URL is accessible, the endpoint returns 2xx, and the HMAC secret matches.

Yes. Create separate webhook endpoints for different purposes — for example, one Slack webhook for CRITICAL findings only, and a generic webhook for all events to your SIEM. Each endpoint has its own event subscriptions and secret.

Available events: finding.created (new finding), vendor.risk_changed (risk score threshold crossed), assessment.completed (vendor submitted response), scan.completed (scan finished), incident.created (new incident), vendor.added (new vendor onboarded). Subscribe to specific events or all events per endpoint.

Enter your ServiceNow instance URL (e.g., https://acme.service-now.com), username, and password. Optionally specify an assignment group sys_id. Finding severity maps to impact and urgency. The control mapping is included in the incident description for proper classification. Credentials are encrypted at rest.

Webhook URLs are automatically masked in audit logs to prevent accidental exposure of internal endpoints, ports, or authentication parameters. The audit log shows only the webhook name and operation type (created, updated, deleted) without revealing the full URL. This protects your internal infrastructure from being logged in shared audit reports.

Under CPS 230, a service provider is material if a disruption to their service could have a material impact on your business operations, financial position, or reputation. Designate vendors as material on their detail page under the Risk Context tab.

The register includes: vendor identity (name, ABN, domain), services provided (from product discovery), service criticality (business_criticality field), geographic locations (from physical_locations), data types handled (data_sensitivity), sub-contractor count (from vendor_dependencies), BCP and exit plan status (manual fields), risk rating, contract expiry, and last assessment date.

Click "Export CSV" to generate a CSV file suitable for APRA CPS 230 reporting. The export includes a metadata header row with your organisation name and generation timestamp. Review the exported data for completeness before submitting to your regulator.

Amber "Missing" badges highlight incomplete data. To fill gaps: add contracts on vendor detail pages, run scans to populate geographic data and product discovery, and update data sensitivity classifications in the vendor Risk Context tab.

Navigate to the vendor detail page, open the Risk Context tab, and enable the "Material Service Provider (CPS 230)" toggle. This adds the vendor to the MSP register.

Business Continuity Plan (BCP) status tracks whether the material service provider has a documented and tested business continuity plan. This is a manual field — update it based on evidence collected through assessments or direct vendor engagement.

An exit plan documents how the organisation would transition away from a material service provider if needed (e.g., vendor failure, contract termination). CPS 230 requires organisations to have credible exit strategies for material arrangements. This is currently a manual field.

Sub-contractor count is derived from the vendor_dependencies table, which tracks known fourth-party dependencies discovered during scans or entered manually. This helps assess concentration risk in your supply chain.

Under APRA CPS 230, a material service provider is a third party whose disruption or failure would materially impact your operations. Mark vendors as material on the vendor detail page in the Risk Context section. Only material vendors appear in this register.

The "Last Review" column shows a green "Current" badge when the last assessment occurred within 12 months, an amber "Overdue" badge if it has been more than 12 months, and a grey "Not assessed" badge if no assessment has been recorded. Use this to identify vendors needing urgent review to meet CPS 230 obligations.

The "Next Due" column shows the scheduled next assessment date. When this date is in the past, the vendor is overdue for review. Set this date in the vendor Governance tab when completing an assessment.

CPS 230 requires documented exit plans and tested business continuity arrangements for material service providers. The "Exit Plan" column shows whether a plan is documented and its current status. The "BCP Tested" column shows the last date a resilience exercise was conducted for this vendor.

Scan the QR code with an authenticator app (Google Authenticator, Authy, 1Password, or any TOTP-compatible app). Enter the 6-digit code to verify setup. Once enabled, you will need to provide a code at each login.

After enabling MFA, save your recovery codes in a secure location. Each recovery code can only be used once. If you lose access to your authenticator app, recovery codes are the only way to regain access to your account.

Organisation administrators can enforce MFA for all team members via Settings > Security. When enforced, users without MFA will be required to set it up on their next login. This is recommended for CPS 234 and ISM compliance.

Any TOTP-compatible authenticator app works: Google Authenticator, Authy, 1Password, Microsoft Authenticator, Bitwarden, and others. The QR code encodes a standard TOTP secret.

Use one of the recovery codes generated during setup. Each recovery code can only be used once. If you have exhausted all recovery codes, contact your organisation admin to reset your MFA.

It depends on your organisation settings. Admins can enforce MFA for all members via Settings > Security. When enforced, users without MFA are required to set it up on their next login. MFA is strongly recommended for CPS 234 and ISM compliance.

Modules let you simplify ChainShield by hiding features your team does not use yet. Core VRM is always on; Standard modules are enabled by default; Advanced modules (Fourth-Party Risk, Financial Risk, BCP/DR) are opt-in. Toggle modules off to reduce sidebar clutter — no data is deleted, and re-enabling restores everything instantly.

Only organisation owners and admins can toggle modules. Viewers and members see a read-only view of which modules are active.

Enable Fourth-Party Risk when you need to track vendor sub-contractors for CPS 230 compliance. Enable Financial Risk for credit monitoring and financial viability checks. Enable BCP/DR Testing to record business continuity exercises. Start with these off and turn them on as your risk program matures.

No. Disabling a module only hides the UI — all underlying data (findings, assessments, remediation tasks) remains intact. Re-enabling the module restores full access.

No. Core VRM (Dashboard, Vendors, Findings) is always on and cannot be disabled. It provides the foundational risk management capabilities.

MSPs deliver SCRM to multiple clients. ChainShield MSP pricing bills per client managed, not per end-user. This allows you to resell ChainShield as part of your service offering.

ChainShield can power your supply chain risk management (SCRM), vendor security assessments, compliance reporting (ISM, CPS 234, CPS 230), attack surface monitoring, incident response, and security dashboards for clients.

For larger MSPs, we offer white-label branding and API access. Describe your needs in the form and our team will follow up with options.

Four categories: Security Alerts (critical findings, risk score changes), Assessment Updates (vendor responses, overdue reminders), Scan Notifications (completed scans, failures), and Digest (weekly portfolio summary).

Choose between real-time (immediate email for each event), daily digest (consolidated at 9am AEST), or weekly digest (Monday morning summary). Real-time is recommended for CRITICAL findings only.

Temporarily mute all notifications during maintenance windows or holidays. Muted notifications are still logged and can be reviewed in the notification centre.

Notification preferences are per-user. Each team member controls their own email notification settings. Organisation-level webhook notifications are configured separately in Settings > Integrations.

Check: (1) your notification preferences are enabled for that event type, (2) the email is not in your spam folder, (3) the organisation has a valid Resend API key configured. Contact your admin if emails are not being sent at the organisation level.

A consolidated email sent Monday mornings summarising the past week: opening summary with average vendor risk score (0-100 scale, where higher is worse) and count of vendors above your configured risk threshold, followed by new findings grouped by severity, risk score trends, assessment status updates, and upcoming contract expirations. Useful for staying informed without real-time noise.

The "Configure Your Organisation" step lets you set your industry sector and applicable regulatory frameworks. Your industry sector (e.g. Financial Services, Healthcare, Government) pre-configures the 7 risk domain weights — for example, Financial Services elevates Operational Resilience to 25% for CPS 230 alignment. Regulatory frameworks (both Australian and international) determine which compliance mappings are checked during scans. You can skip this step and configure later in Settings.

Work through each step: configure your organisation name, set industry sector and regulatory frameworks, add a vendor, set risk context (criticality, data sensitivity), run your first scan, review findings, and invite your team. Each step can be completed independently and in any order.

Select the Australian regulatory frameworks that apply to your organisation: ISM (government), CPS 234 (APRA-regulated financial services), CPS 230 (operational resilience), SOCI (critical infrastructure), NDB (all organisations handling personal information), Privacy Act, and Cyber Security Act 2024. These determine which compliance mappings are checked during scans.

Yes. All onboarding settings (industry sector, regulatory frameworks, vendor data) can be changed at any time from the Settings page. The onboarding wizard is just a guided way to configure the essentials.

The first scan typically takes 5-10 minutes, running the full pipeline (discovery, enrichment, CVE correlation, AI analysis, compliance mapping) — there is no separate quick/full scan choice. Results appear progressively as each phase completes.

No. Add vendors as you go. Start with your most critical vendors (Tier 1) to get immediate value. ChainShield discovers their assets and generates a risk profile automatically from just a name and domain.

Click "Add contact" to create a contact that is immediately visible to all organisations monitoring your vendor. Contacts added here are globally visible (not org-private). A welcome email is sent to the contact if an email address is provided, unless you are adding yourself.

Use the pencil icon to update a contact's name, email, or role. Use the trash icon to remove a contact. You can only manage contacts that were added from the portal — contacts added by an organisation through their own portal are read-only here.

The confidence badge (High, Medium, Low) on discovered candidates reflects how reliably the scan pipeline matched a contact to your vendor. High (green) = found on a structured source such as security.txt. Low (red) = inferred from a team page or WHOIS field.

Click Confirm to mark a discovered contact as verified. Confirmed contacts are visible to linked organisations and can be assigned to products.

Click Reject to soft-delete a false positive. The pipeline will not re-suggest it. This action is reversible by your vendor admin.

Contacts added from the vendor portal are publicly visible to all organisations that have this vendor in their portfolio. They are marked as public (not org-private). A contact added by an organisation through their own interface is private to that organisation only.

Organisations that have this vendor in their vendor portfolio can see confirmed contacts. Rejected contacts and unreviewed candidates are not visible to organisations until confirmed.

Some contacts may have been added privately by an organisation (they are labelled Org-private from the org side). The vendor portal cannot edit or delete those contacts — they are managed by the organisation that created them.

Each paid tier includes a set number of vendors. If you add more vendors than your included quota, you are charged an overage rate per extra vendor per month: $49 on Starter, $39 on Essentials, $29 on Pro. Enterprise uses negotiated contract terms with no per-vendor overage charges.

Starter is the most cost-effective choice below 10 vendors. At around 20 vendors the Essentials base fee ($975) becomes comparable to Starter with overages ($980). At around 34 vendors, Essentials overages bring you close to the Pro base price. Use the comparison cards on the pricing page to find your break-even point.

The Free plan is capped at 2 vendors and includes a 14-day Starter trial on signup. During the trial your organisation can monitor up to 10 vendors with weekly scans and full report access. After the trial, the account reverts to Free (2-vendor cap) unless you subscribe.

Enterprise pricing is negotiated directly. Use the "Contact sales" button to email sales@chainshield.com.au with your requirements. Enterprise contracts include a dedicated success manager, negotiated vendor scale, SSO/SAML, white-label reports, and compliance assistance.

Overage is the charge per vendor above your included quota each month. If you are on Starter (10 included) and add a 15th vendor, you pay 5 x $49 = $245 in overage on top of the $490 base fee. Overages are calculated on the peak vendor count for the billing period.

Included vendors are those covered by your base monthly fee. Starter includes 10, Essentials includes 25, Pro includes 50. Free is hard-capped at 2 with no overage option.

New Free accounts receive a 14-day Starter trial automatically on signup. During the trial you get Starter-tier benefits: up to 10 vendors, weekly scans, PDF reports, and assessment questionnaires. No credit card is required. After 14 days the account returns to the Free tier.

Dunning is the period after a failed payment where ChainShield retries the charge before restricting access. During the dunning window your account remains active. If payment fails after three retries your account is suspended until the overdue invoice is settled.

Yes. If you access ChainShield through a Managed Service Provider, your MSP may apply custom pricing or discounts via their account settings. Contact your MSP for your specific rates. The prices on chainshield.com.au/pricing reflect the standard ChainShield catalogue.

Data is populated automatically when a vendor completes a Privacy & Data Protection assessment (source authority: Assessment). You can also add or edit data manually (source authority: Manual). A higher source authority value means lower precedence - assessment data wins over manual entry, which wins over agent discovery.

The DPA (Data Processing Agreement) status tracks whether a formal agreement is in place with this vendor. If the DPA expiry date is within 90 days, a warning indicator appears. Expired or refused DPAs should be escalated - they indicate a gap in contractual data protection obligations.

The Data Residency card shows where this vendor stores your data. The Cross-Border Transfers card tracks whether data is sent overseas and what safeguards apply (APP 8 of the Privacy Act requires APP entities to take reasonable steps to ensure overseas recipients protect the information). ISO country codes are used - AU = Australia, US = United States.

Sub-processors are third parties the vendor uses to process data on your behalf. Each sub-processor row shows their country, data types they access, and whether a DPA is in place. A DPA with the primary vendor does not automatically cover sub-processors - check the 'Covers sub-processors' field.

It shows a structured, queryable record of how this vendor handles your data - including DPA status, data residency, cross-border transfers, data types processed, and consent and retention controls. This information is more useful for auditors and compliance checks than raw findings or assessment response blobs.

When a vendor submits a Privacy & Data Protection assessment, ChainShield automatically extracts the structured fields and saves them here. You can also add or edit data manually using the Edit button. In future phases, the privacy agent will populate fields it can discover from the vendor's public privacy policy.

Source authority indicates the confidence level of the data. Assessment data (authority 2) is the most trusted - it comes from the vendor's signed responses. Manual entry (authority 4) is human-entered and takes precedence over agent-discovered data (authority 5). When a new assessment is submitted, it replaces the previous record and the old data is archived for audit trail.

Data residency is where the vendor stores the data (e.g., AWS Sydney = AU). Cross-border transfers is when data is sent to another country for processing (e.g., sending AU data to a US analytics service). Both affect Privacy Act APP 8 obligations - you need to know about both, not just where data is stored.

Under the Australian Privacy Act 1988, you have the right to access, correct, and delete your personal data. ChainShield complies with all Australian Privacy Principles (APPs). We do not sell your data to third parties.

We collect your name, email, and organisation details when you create an account. We also collect information about vendors from publicly available sources only (open-source intelligence / OSINT). We never use private or proprietary data without permission.

For privacy questions or data subject requests, contact privacy@chainshield.com.au. Response time: 30 calendar days (Australian Privacy Principles requirement).

For every vendor ChainShield monitors, the product inventory captures each product name, version, deployment model (SaaS, self-hosted, hybrid), lifecycle phase (Full Support through End of Life), and hosting provider. This replaces manual tech-stack spreadsheets and keeps your risk picture current as vendors ship updates.

The inventory is derived from evidence: ChainShield scanner, HTTP fingerprinting, SBOM submissions, and cross-validation by seven domain-aligned AI agents. Low-confidence detections go through a human review gate before appearing in your organisation's inventory.

This page describes the feature for prospective users. Once signed in, the authenticated /products page shows your organisation's live inventory, scoped to your vendor portfolio with per-org criticality, data sensitivity, and usage context layered on top.

The sharing section lets you choose who can see this response. "Requesting org only" is the default and safest option — only the organisation that requested the assessment can view your answers. Widening to "all linked orgs" shares your answers with every organisation that has your company in their vendor portfolio.

When you select "all linked orgs", a confirmation dialog will tell you how many additional organisations will gain access. Review this before confirming. You can narrow the visibility back at any time while the response is in draft.

After you submit a questionnaire, the sharing setting is locked and shown as read-only. The "Submitted" badge indicates this state. Contact your assessing organisation if you need to change visibility on a submitted response.

Alerts are scraped from official regulator RSS feeds and advisory pages. Each alert is keyword-matched against a curated list covering cybersecurity, privacy, operational resilience, and financial risk topics. The feed is global — it is not filtered to your specific vendors. Use it to identify regulatory developments that may affect your vendor risk posture or upcoming audit obligations.

The keyword filter matches against the exact keywords our system tagged the alert with (e.g. "ransomware", "CPS 234", "NDB"). Type a keyword to narrow the list. For partial matches use the source filter to narrow by regulator first.

Sort by business impact (not just severity) to focus on findings that matter most to your organisation. A MEDIUM finding on a Tier 1 vendor with sensitive data may deserve more attention than a HIGH finding on a Tier 3 vendor.

Use the vendor portal to communicate findings and track remediation. Vendors can update their status and provide evidence of fixes without needing a ChainShield account. The next scheduled scan will automatically verify whether the issue is resolved.

Track how quickly your vendors resolve findings. The average remediation time is one of 6 Key Risk Indicators (KRIs) reported on the dashboard and in board reports. Target: less than 14 days for green status. Vendors with remediation times over 30 days are flagged red.

If Jira or ServiceNow is configured, click "Create Ticket" on any finding to push it to your ticketing system. The ticket includes severity, vendor name, description, and remediation guidance with a link back to ChainShield.

Remediation tasks can come from two sources: scan findings (automated — created when a finding requires tracking) and self-assessment remediations (org-private — created when your organisation records a gap in a vendor self-assessment). Self-assessment remediations are only visible to your organisation. You can deep-link to a specific task by navigating to /remediation?id=<task_id> from the Self-Assessment Remediations sub-tab.

Accepted means your organisation has reviewed this task and formally accepted the residual risk — the issue is acknowledged but not being actively remediated. Won't Fix means your organisation has decided this task will not be remediated (e.g. out of scope or mitigated elsewhere). Both are terminal states and appear with distinct blue and slate styling respectively.

When a scan no longer detects an issue that was previously found, the finding is automatically set to SYSTEM_RESOLVED. This means the vendor has fixed the problem. SYSTEM_RESOLVED findings are purged after 12 months.

RESOLVED is manually set by a user to indicate the vendor has fixed the issue. SYSTEM_RESOLVED is automatically set by the scan pipeline when the issue is no longer detected. Both are considered "resolved" for reporting purposes.

Sort by business impact rather than severity alone. A MEDIUM finding on a Tier 1 CPS 230 Material Service Provider handling sensitive data may be more urgent than a HIGH finding on a Tier 3 vendor with minimal data access. CRITICAL findings should always be triaged within hours.

When an assessment question reveals a gap or concern (e.g. "No" on insurance, low score on compliance capability), you can create a remediation action to track the fix. Remediations link back to the specific assessment response that triggered them, preserving the audit trail.

Remediations move through status: open (new) -> in_progress (assigned to owner, work underway) -> resolved (completed, awaiting confirmation), accepted (gap acknowledged but owned by vendor), or wont_fix (deliberate choice to not address). The system records who changed the status and when.

Use the Status filter at the top to narrow the view to a specific remediation state. For example, filter to "Open" to see items needing assignment, or "In Progress" to track active work.

Click any remediation row to open the detail panel. Assign it to a user (owner_user_id), set a due date, add description text, and attach evidence documents. Every change is recorded in the audit log with the author and timestamp.

Attach supporting documents to a remediation (corrective action plan, vendor response, audit report, resolved ticket). Evidence files are linked and searchable. This creates a complete record of the remediation journey for compliance auditors.

Remediations are visible only to your organisation. The vendor cannot see them. This is a strict boundary: remediations exist solely for internal tracking and compliance evidence.

No. Remediations are organisation-private. The vendor cannot see them. If you want to request remediation from the vendor (e.g. "update your compliance certification"), that is a separate communication outside ChainShield.

Any authenticated user with access to the vendor can create a remediation. Typically this is done while filling in the assessment form (clicking "Create Remediation" on a response), but you can also create one directly from the Remediations tab.

Click the remediation row and update the Owner field. The system records the change in the audit log with the timestamp and author. You can reassign at any time.

No. Remediations can only be archived (soft-deleted, hidden from view). Hard deletion is not allowed to preserve the audit trail. To hide an archived remediation, filter out archived items using the view toggle.

The event log records every change: status transition, owner assignment, due date update, description change, and evidence attachment. This creates a forensic audit trail useful for compliance evidence, incident investigations, and accountability.

Many vendor websites return a branded navigation skeleton (HTTP 200) for any unknown path — a "soft-404". ChainShield's URL verifier (CS-1546) probes a random path on each vendor domain to capture this fingerprint, then rejects any discovered URL whose body matches the fingerprint. This prevents hallucinated or guessed paths from being saved as verified resource URLs. URLs found via the vendor's sitemap.xml or robots.txt are used as candidates instead, since they are known-good paths. If a legitimate URL is incorrectly rejected, contact your administrator to review the vendor's soft-404 fingerprint settings.

When MSPs deliver risk reports to their customers, they often need the report to reflect the MSP or customer brand rather than ChainShield. Setting a custom brand replaces the ChainShield logo and name on PDF covers, headers, and footers, and prefixes exported filenames with your organisation name.

Report branding resolves in three levels: (1) Organisation-level override — set by an org admin and applies only to that org. (2) MSP-level brand — set by an MSP admin and applies to all customer orgs that have NOT set their own override. (3) ChainShield default — used when no custom brand is set at either level. Set an org override to give one customer a distinct brand while your other customers use the MSP brand.