Snapshots are scheduled reports that capture telemetry and policy state from Elisity Cloud Control Center (CCC) for a defined reporting period. Use them to share posture summaries, compliance evidence, and policy baseline changes with auditors, risk owners, and change-control teams. Generated reports are saved in the Snapshots Archive for preview and download.
Each schedule selects a report source, reporting period, and site scope. The source determines the report content and format. Compliance and configuration analysis reports also retain an evidence package that records the data used to generate the report. Unavailable evidence is identified in the report rather than treated as proof that a control is satisfied.
For reports that you generate on demand and download immediately, see Generate PDF Reports.
Compliance analysis reports present auditable evidence of platform controls relevant to selected framework requirements. They do not assess a tenant against a framework in full, and they do not produce a certification or a pass mark.
Prerequisites
| Requirement | Details |
|---|---|
| Cloud Control Center access | Administrator access to create snapshot schedules and view generated reports. |
| Compliance reports | Classify the devices and workloads in scope and cover them with Policy Groups and enforced policies. Enable audit logging to include configuration-change activity. |
| PCI DSS scope | Apply PCI_APP or PCI_DB labels to the appropriate Cardholder Data Environment assets. Configure the CDE Policy Groups with match criteria that select these labels, and configure policies covering those groups. |
| Policy Baseline Drift | Enable audit comments and designate baseline policies through creation or policy review comments containing baseline. Assign source and destination Policy Group Security Levels for meaningful criticality bands. |
Snapshot sources
The source determines what the report contains, which sections appear, and the format the report is rendered in. Select the source in the first step of the Create Snapshot Schedule wizard.
| Source | Format | What it reports |
|---|---|---|
| Executive Summary (Dashboard) | A period summary of the tenant's posture, drawn from the same figures presented on the Executive Summary dashboard. | |
| IEC 62443 (Compliance Analysis) | MD | Maps Elisity segmentation and policy capabilities to selected IEC 62443 controls and presents the supporting evidence for each. |
| HIPAA Security Rule (Compliance Analysis) | MD | Evidences the technical safeguards of the HIPAA Security Rule, one control area per row, with the Security Rule reference, the coverage the platform can evidence, and a status. |
| PCI DSS (Compliance Analysis) | MD | Reports against Requirements 1, 7, 10 and 11 of PCI DSS v4.0.1, scoped to the Cardholder Data Environment that you define with labels. |
| Policy Baseline Drift (Configuration Analysis) | MD | Reports modification and deletion of the matrix policies you have designated as your security baseline, with a severity and a criticality band on every finding. |
Executive Summary (Dashboard)
The Executive Summary source produces a periodic posture document for management reporting. It is the appropriate source when the audience needs the headline figures for a period rather than the underlying configuration record. The report is drawn from the same figures presented on the Executive Summary dashboard, and its pages follow that dashboard’s own sections, among them the site summary, the Virtual Edge estate, IdentityGraph, and traffic vectors. Each page presents the period’s headline counts alongside the charts they are drawn from.
This is the one source rendered as PDF. Its row in the Snapshots Archive carries a Format of PDF where every other source carries MD, and its row action menu offers Download as PDF and Preview Snapshot only.
Preview Snapshot opens a PDF report in a new browser tab, using the browser’s own PDF viewer with its page thumbnails, zoom, print, and save controls, rather than in the preview drawer the Markdown reports use.
IEC 62443 (Compliance Analysis)
The IEC 62443 source produces a compliance analysis report that relates the tenant's segmentation and policy state to selected controls of the standard, together with the evidence behind each statement. It is the appropriate source when an assessor has asked what the platform contributes to an industrial control system security program, and what evidence supports that contribution. The report presents auditable evidence of platform controls relevant to selected requirements of the standard.
The report opens with an executive summary stating a coverage rollup across the in-scope elements, followed by a matrix organised by Foundational Requirement. For each Foundational Requirement, the matrix reports the highest capability Security Level the platform can contribute toward a zone’s target Security Level, which is a capability ceiling rather than an achieved level, and restates the target Security Levels the asset owner has declared on the zones. Where the per-element verdicts behind a Foundational Requirement have not been evaluated, the rollup reads Not determinable rather than a figure.
HIPAA Security Rule (Compliance Analysis)
The HIPAA Security Rule source presents network and policy evidence relevant to selected Security Rule safeguards. The report presents auditable evidence of platform controls relevant to selected requirements of the Rule. The Security Rule is broader than network security, and the report addresses only the technical safeguards the platform can evidence.
The report opens with an overall technical control coverage table, one row per control area, giving the Security Rule reference, the coverage the platform can evidence for that area, and a status.
| Control area | Security Rule reference |
|---|---|
| Risk Management | §164.308(a)(1) |
| Information Access Management | §164.308(a)(4) |
| Security Monitoring & Evaluation | §164.308(a)(5), (6), (8) |
| Access Control | §164.312(a) |
| Audit Controls | §164.312(b) |
| Integrity | §164.312(c) |
| Authentication | §164.312(d) |
| Transmission Security | §164.312(e) |
| Network Segmentation | Supporting control |
Each row carries a status. Strong and Partial indicate that the platform holds evidence for the control area. Weak indicates that the evidence available is thin. Not Assessed indicates that the element depends on data the platform does not yet hold, and the row reports Not Assessed rather than a zero. The overall coverage figure the report states is marked provisional, is computed only over the elements assessed in that run, and excludes Not Assessed and Not Applicable elements; the report explains the exclusions in its Scope Limitations section.
Configuration-change activity is reported over a rolling 30-day window.
Important: Read the Transmission Security row as a statement about reachability. The platform evidences which devices and workloads are permitted to communicate with which others, and the policy that enforces it. It does not evidence that electronic protected health information is encrypted in transit. That control is satisfied and assessed outside the platform.
The platform does not assess administrative and physical safeguards in full. Technical evidence may support selected administrative safeguard activities. The report lists them among the areas that require additional controls or evidence outside Cloud Control Center, each with its reason recorded in the report’s first appendix. The standards listed are workforce security, security awareness and training, contingency plan, and business associate contracts and other arrangements under §164.308, together with facility access controls, workstation use, workstation security, and device and media controls under §164.310.
Three conditions determine whether the report is meaningful on your tenant:
- Devices are classified, so that medical and connected medical device classes resolve rather than falling into an unknown class. Classification depends on connector enrichment.
- Policy Groups and enforced policies cover the clinical assets you intend to evidence. An asset outside every Policy Group contributes nothing to the access control and segmentation rows.
- Audit logging is enabled, so that configuration-change activity is recorded within the 30-day window.
PCI DSS (Compliance Analysis)
The PCI DSS source reports against PCI DSS v4.0.1. The report presents auditable evidence of platform controls relevant to selected requirements of the standard. PCI DSS defines twelve requirements; this report covers four, and the remaining eight are outside its scope.
The report opens with a disclaimer stating what it is and is not, followed by a Document Control table recording the reporting period and window, the version of the standard assessed against, the labels that resolved the Cardholder Data Environment, the number of registry elements assessed, and the evidence package filename.
| Requirement | What the report evidences |
|---|---|
| Requirement 1 | Network security controls, evidenced by the policy governing traffic into and within the Cardholder Data Environment. |
| Requirement 7 | Access restricted by need to know, evidenced by which Policy Groups are permitted to reach Cardholder Data Environment assets. |
| Requirement 10 | Logging and monitoring, evidenced by the recorded change events and review activity for the period. |
| Requirement 11 | Testing of security systems and processes, evidenced by the review activity recorded against network security controls. |
The report scopes itself to the Cardholder Data Environment (CDE) using the labels PCI_APP and PCI_DB. A device is in scope when it carries either label. A Policy Group is in scope when its match criteria select those labels. Apply the labels and configure the matching Policy Groups before scheduling the report. An empty resolved CDE scope leaves the report without the evidence needed to assess the relevant controls.
A PCI DSS schedule is restricted to a reporting period of Last Week or Last Month. The report covers the CDE scope, the change events recorded within the CDE, a summary of those changes, and the review activity recorded against network security controls.
The report states its own blind spots in its final appendix, and that appendix is worth reading before the report is circulated. Three of them shape how the figures are read: a policy creation event does not carry a policy identifier, so creations are scoped by the endpoints of the Policy Groups involved rather than by the policy itself; audit comments are read from the change record, so a change made without a comment carries no narrative; and changes attributed to SYSTEM are not counted as attributed activity.
Policy Baseline Drift (Configuration Analysis)
The Policy Baseline Drift source answers a change-control question: of the policies designated as the security baseline, which have been modified or deleted since they were designated, by whom, and how serious is each change. Membership of the baseline is declared by tagging policies, so the report describes drift away from an intentional standard rather than raw change volume. The report provides auditable evidence of changes to the declared matrix policy baseline.
Open a generated drift snapshot in the preview drawer to read it without downloading it. The drawer is titled with the schedule name and renders the full report. The report opens with its title and a header line stating the tenant, the reporting period, the site scope, the generation timestamp, the report identifier, and the platform version the report was generated on. A Document Control table then restates the tenant, reporting period, and platform version, and adds the number of policy sets in the baseline and whether a baseline has been established.
The Executive Summary section that follows sets the current period against the prior period, metric by metric: baseline members, members with a drift finding, conformance, total findings across direct and indirect drift, findings broken out by severity, findings landing on critical and high-criticality members, comment coverage, members deleted in the period, and findings remediated in the period. A metric with no comparable prior figure shows an em dash rather than a zero.
Important: Until at least one policy is tagged into the baseline, the report has nothing to measure. Counts report zero, percentages without a denominator display an em dash and the report displays a No baseline members yet notice, which names the two ways to begin: creation-tagging and review-tagging. This is expected on a tenant that has not yet declared a baseline; see Establishing a policy baseline.
Creating a snapshot schedule
Step 1. Navigate to Dashboards > Snapshots.
Step 2. Click + Create Schedule. The Create Snapshot Schedule wizard opens on the Snapshot Details step.
Step 3. Enter a Snapshot Name of up to 100 characters. The name identifies the schedule on the Snapshots Schedule tab, labels every snapshot the schedule generates, and titles the preview drawer, so use a name that states the report and its audience.
Step 4. Select the Source, then set the site scope and the reporting period. Snapshot Name and Source are the required fields on this step. The period defines the window of data the report covers, for example Last Week. Site scope limits the report to a subset of sites; leave it unrestricted to report on the whole tenant.
Step 5. Optionally enter a Description of up to 500 characters, then click Next. The description is carried through to the Snapshots Archive listing.
Step 6. On the Snapshot Scheduling step, define when the schedule runs. A schedule either runs once or repeats, generating a new snapshot on each run.
Step 7. Review the Summary step and submit the schedule. The schedule appears on the Snapshots Schedule tab, and generated snapshots appear on the Snapshots Archive tab as each run completes.
The Policy Baseline Drift report reads the audit trail, which is exported once per day. Events recorded after the last completed export but before the end of the reporting period are not yet available when the report runs, and because the next period begins where this one ends, those events do not appear in a later report either. Scheduling the report to run after the daily export window keeps this gap to a few minutes.
Snapshots Archive
The Snapshots Archive tab lists every snapshot that has been generated, most recent first.
| Column | Description |
|---|---|
| Schedule Name | The name of the schedule that produced the snapshot. A recurring schedule contributes one row per run, so the same name appears once for each generated snapshot. |
| Source | The report source the schedule was created with, such as IEC 62443 or Policy Baseline Drift. |
| Status | The outcome of the run. Success indicates the report rendered and is available to preview and download. |
| Format | The format the report is rendered in, which follows the report source rather than being set on the schedule. The compliance and configuration analysis reports are listed as MD and the Executive Summary report as PDF. The column is read-only. |
| Date Generated | When the run completed. Click the column header to reverse the sort order. |
| Description | The description entered on the schedule, or -- when none was entered. |
| Actions | Opens the row action menu for previewing and downloading the snapshot. |
Use Search to filter the list by schedule name, and the toolbar controls to filter the grid, choose which columns are displayed, reload the list, and export the list itself.
Previewing and downloading a snapshot
Step 1. On the Snapshots Archive tab, locate the row for the snapshot you want.
Step 2. Click the actions control at the end of the row.
Step 3. Select an action:
- Download as Markdown saves the report as a Markdown file. This action is offered on the compliance and configuration analysis reports, which are rendered as Markdown.
- Download as PDF saves the report as a PDF file. This action is offered on every report.
- Preview Snapshot opens the report for reading without downloading it. A Markdown report opens in a drawer over the archive; click Close to return to the list. A PDF report opens in a new browser tab.
The actions offered depend on the report’s format, shown in the row’s Format column. A report listed as MD can be downloaded as either Markdown or PDF. A report listed as PDF is available as PDF only.
Establishing a policy baseline
The Policy Baseline Drift report measures change against a baseline that you declare. A matrix policy becomes a baseline member the moment it receives either of two signals, whichever comes first:
-
Creation-tagging — the policy's audit comment at creation contains the word
baseline. Matching is case-insensitive. -
Review-tagging — a review comment recorded against the policy by the Complete Policy Review action contains the word
baseline. This is how a policy that already exists joins the baseline, without being deleted and recreated.
Membership begins at the earliest matching event and is permanent for the purposes of this report. Later comments on modification events do not remove or re-tag a member, and a repeated matching review has no additional effect.
Because membership is driven by free text, agree an audit comment convention before tagging. A convention such as baseline — <change ticket> — <owner> keeps the tag word present, records the approval behind the designation, and reads well in the report's attribution section. For guidance on entering audit comments, see Audit Comments.
Important: Tag policies only after they are in their approved state. Changes made to a policy before it is tagged are not drift; changes made after it is tagged are.
What counts as drift
Every modification or deletion recorded against a baseline member after it joined the baseline is direct drift. A modification or deletion of a Security Profile that a member references is indirect drift, and is attributed to every member that references that profile.
Where the platform mirrors a member's change onto its Return-direction twin, the twin's events are folded into the forward member's finding and marked as arriving via the return path, rather than reported as a second member.
The report covers matrix policies and the Security Profiles they reference. The following are outside its scope:
- Policy Group match criteria and static subnets
- Access Policies
- Role-based access control and connector configuration
- The Virtual Edge and Virtual Edge Node estate
- Observed traffic outcomes
Severity and criticality
Each finding carries two independent dimensions. Severity is assigned mechanically from the kind of change observed, never from its size or its narrative impact.
| Severity | Assigned when |
|---|---|
| High | A baseline member is deleted; Monitor Mode changes from Deployed to Simulation or External; the Final Action changes from the member's baseline value; or a Security Profile used as a member's Final Action is edited or deleted. |
| Medium | The referenced Security Profiles change while the Final Action stays the same; a Security Profile in a member's ordered profile list is edited or deleted; or Monitor Mode changes between Simulation and External. |
| Low | Monitor Mode changes to Deployed from Simulation or External; only the name, custom name, description, or vendor label changes; only the audit comment changes; or a referenced Security Profile is renamed or annotated. |
A change request that produces no field difference is not a finding. It is excluded and counted separately as noise, which keeps a repeated save from inflating the drift figures.
Criticality describes the member the finding lands on rather than the change itself. It is the sum of the source and destination Policy Groups' declared Security Levels, each in the range 0 to 4, with an unassigned level counted as 0. The resulting score of 0 to 8 is banded as follows.
| Criticality band | Combined Security Level score |
|---|---|
| Critical | 7 to 8 |
| High | 5 to 6 |
| Medium | 3 to 4 |
| Low | 0 to 2 |
Neither dimension modifies the other, and each finding header shows both. A low-severity change on a critical member and a high-severity change on a low-criticality member are therefore distinguishable at a glance, which is what allows a reviewer to triage a period's findings without reading every one.
In the report, a finding is headed by the affected policy, then states its severity and its criticality band on the line beneath, and lists every constituent audit event with its timestamp, the fields that changed, the actor, and the audit comment recorded with the change.
Assign Security Levels to the Policy Groups that carry your most sensitive traffic before relying on the criticality band. Where a Policy Group has no Security Level, it contributes 0 to the score, and findings on that member are banded lower than their real importance.
Reading the report
A generated drift report is organized into the following sections.
| Section | Contents |
|---|---|
| Document Control | Tenant, reporting period, platform version, baseline size, and whether a baseline has been established. |
| Executive Summary | Current period and prior period figures side by side, for period-on-period comparison. |
| Baseline Definition and Scope | The membership rules, the drift rules, and the severity and criticality classifications applied in this report. |
| Drift Summary | Findings aggregated for the period. |
| Detailed Findings | Each finding individually, with its severity, the affected member's criticality band, and the change that triggered it. |
| Attribution & Comment Coverage | Who made the changes, and what proportion of commentable changes carried a comment. |
| Trend | Movement in baseline size, findings, and comment coverage across periods. |
| Systemic Observations | Patterns visible across findings rather than in any single one. |
| Method, Limitations & Evidence | How the report was produced, what it cannot see, and the reference to the evidence package. |
| Appendices | The baseline member inventory, every drift event in the period, and the report generation manifest. |
Read the Method, Limitations & Evidence section before circulating the report to an assessor. It states plainly what the report does not cover, which is what an assessor asks first.
Verifying a snapshot configuration
Step 1. Navigate to Dashboards > Snapshots and open the Snapshots Archive tab.
Step 2. Confirm that a row exists for the schedule, that Status reads Success, and that Date Generated falls within the expected run window. A recurring schedule adds one row per run.
Step 3. Open Preview Snapshot from the row’s action menu. For a compliance or drift report, confirm the tenant and reporting period in Document Control and the site scope in the report generation appendix. For Executive Summary, confirm the reporting period and scope in the PDF report.
Step 4. For a Policy Baseline Drift snapshot, confirm that Document Control reports a non-zero number of policy sets in the baseline. Document Control counts the policy sets that contain baseline members rather than the members themselves, so use the baseline member inventory appendix to confirm the individual policies you tagged. A count of zero means that no baseline members were resolved for this run. Check the tagging comments, report scope, and audit export timing.
Troubleshooting snapshots
| Symptom | Resolution |
|---|---|
| The drift report shows zero baseline members | No baseline members were resolved for this run. Confirm that audit comments are enabled and that the intended policies have a creation or review comment containing baseline. Check the report scope and allow the audit trail export to complete before the next run. |
| A policy you consider part of the baseline produces no findings | Check the baseline member inventory appendix. Confirm that the policy was tagged before the change, that the change falls within the reporting period, and that the audit export includes it. A change that produces no field difference is excluded as noise. |
| A recent change is missing from the report | Changes made after the reporting period ended are reported in the next period. Changes made in the minutes before the period ended may fall after the last audit trail export; schedule the report to run after the daily export window. |
| Findings on important policies are banded lower than expected | Criticality is derived from Policy Group Security Levels. Assign Security Levels to the source and destination Policy Groups, and the band updates on the next run. |
| Comment coverage is low | Coverage counts commentable changes that carried a comment. Adopt an audit comment convention for policy changes so that each finding can be traced to an approval. |