Key questions. Clear answers.

Panop validates exploitability first, then weights each confirmed finding against operational and business context — asset criticality, data sensitivity, availability constraints and ownership. Severity score alone does not set the order. The result is a remediation queue ranked by what is genuinely reachable in your environment and what it would cost the business, rather than a list of every alert a scanner produced.

Yes. Critical assets, sensitive environments, availability constraints and brand-impacting systems can each be weighted differently, so two findings with the same technical severity can sit far apart in the queue. Context flows in from the systems you already run — asset inventories, ownership records and CMDB data — through Panop's integrations, so weighting reflects your organisation rather than a generic default.

The Decision Layer is the stage where Panop turns validated exposure into an ordered set of actions. It takes confirmed findings from active testing, combines them with business and operational context, and produces a ranked remediation queue with owners attached. It is what separates Panop from a scanner — the output is a decision about what to do next, not an inventory of everything found.

Panop runs targeted tests against the services and technologies it actually detected, rather than exhaustive generic scans, which produces fewer findings to begin with. Each finding is then validated to confirm whether it is genuinely exploitable, so theoretical issues are separated from demonstrated access before triage. What reaches an analyst is confirmed, ranked and evidenced, not a raw scanner export.

A validated exposure is one Panop has actively tested and confirmed to be reachable and exploitable, with the reproduction path recorded as evidence. It is distinct from a scanner finding, which reports that a condition exists without establishing whether an attacker could use it. Remediation teams act on demonstrated access rather than on a severity score, and every fix is re-tested to confirm the path closed.

Panop can run as a standalone exposure management platform, and it also integrates with security stacks that are already in place. Existing SIEM, ticketing and CMDB systems stay where they are, with Panop acting as the layer that decides what deserves action. Validated, ranked risk is routed into those tools rather than replacing them, so nothing has to be decommissioned to adopt it.

Yes. Panop's integrations run in both directions. Asset data, ownership and business context flow in from the systems you already operate, sharpening how findings are prioritised. Validated, prioritised risk flows out as a ticket for the asset owner, context for your SIEM, updates for your CMDB and evidence for your auditors. A REST API and a CLI expose the same data programmatically.

Integrations are what make prioritisation specific to your organisation rather than generic. Your asset data, ownership records and business context flow in to sharpen how findings are weighted; validated, prioritised risk flows out to the teams and systems that act on it. Define the routing policy once, and only the decisions that genuinely need human judgment reach a human. The platform is built for complex environments, not built around integration.

Yes. Findings are routed automatically to the asset owner in the tool that team already uses, with the validation context and reproduction path attached. The Alert Manager escalates only what genuinely needs a human. After a fix is applied, Panop re-tests the path to confirm it closed and that no new one opened, so closure is verified rather than assumed.

Panop generates compliance evidence as a by-product of continuous monitoring rather than as a separate reporting exercise. Each validated finding is linked to the NIS2, DORA, ISO 27001 or EU AI Act control it affects, and dated records of what was tested and found accumulate as operations run. The audit trail is current on the day it is requested, not assembled in the weeks before a review.

Panop helps organisations continuously test controls, validate their security posture and generate audit-ready evidence across:

• Security frameworks and standards:ISO/IEC 27001:2022, ISO/IEC 27017:2015, ISO/IEC 27018:2019, NIST, CSA CCM.
• Regulatory and compliance requirements: PCI DSS 4.0, NIS2, DORA, GDPR, FedRAMP and FINMA.
• Security best practices and benchmarks: OWASP Top 10, CIS benchmarks for AWS, Azure, GCP and M365.
• Custom requirements: Organisation-specific security policies and tailored control frameworks.

Yes. Panop produces dated, attributable records of what was tested, what was found and what was remediated, exportable for audit, compliance and internal review. Because the same validation data maps to several frameworks, one evidence set can be reused across NIS2, DORA and ISO 27001 reporting instead of rebuilding a separate pack for each auditor. Scope gaps surface before an auditor finds them.

Panop re-tests controls whenever the underlying infrastructure changes, so drift is flagged between audit cycles rather than discovered at the next review. Continuous discovery keeps the asset inventory current as environments change, and continuous validation keeps the remediation queue ordered by what is actually reachable. Teams therefore work from a picture of the estate as it is now, not as it was at the last scan.

Customer data is hosted in Switzerland, in certified data centres with enterprise-grade physical and logical security controls. Swiss data residency applies to the exposure data the platform collects. Panop SA is itself a Swiss company, registered at Chemin du Château 4b, 1023 Crissier. Sub-processors and the data processing locations that apply to them are listed on the Sub-Processors page.

Panop applies layered controls — encryption in transit and at rest, authentication and access controls, continuous monitoring, documented governance processes and secure engineering practices across the development lifecycle. Controls are documented rather than asserted, and additional security documentation can be provided on request. Formal certification processes are currently underway; what is in place today is described on the Trust Center.

Access to systems and customer data follows least-privilege principles and is restricted to authorised personnel. Access requests are reviewed and approved before they are granted, and entitlements are periodically reassessed according to documented procedures rather than left in place by default. Further detail on access governance can be provided as part of a customer security review.

Formal certification processes are currently underway. Panop is not yet able to publish completed certificates, and does not claim certifications it has not obtained. In the meantime, security documentation, compliance information and supporting audit materials can be provided on request, and the controls already in place are described on the Trust Center and the Security & Compliance page.

Yes. Security documentation, compliance information, sub-processor details and supporting audit materials can be provided on request, typically as part of a vendor security review or procurement process. The Trust Center covers certifications, policies and infrastructure detail, the Sub-Processors page lists processing locations, and anything not published there can be requested through the contact form.