Application user guide

Operating principles

Automated technical results are not a substitute for auditor judgment, organizational context, risk acceptance, or the Statement of Applicability. When evidence cannot be collected, the toolkit uses NO_DATA / Not Collected rather than inventing a PASS or FAIL.

Runtime architecture

The GUI launches Invoke-ISOAudit.ps1 directly as the assessment worker and retains that worker PID. There is no intermediate bootstrap process and no live redirected Worker-Launch.log inside the evidence tree. This avoids the file-sharing failure that previously stopped collectors during evidence-integrity processing.

The GUI validates launch inputs, creates the run package, starts the actual worker, and then reads status/progress telemetry. The worker validates credentials/secrets again before collector execution. The status window and cancellation path are independent of collector runspace count.

Settings - required before running

Credentials and secrets

Windows / AD / GPO

Use Change Credentials to load the authorized audit account into the session. The credential handoff is encrypted and validated before launch and again by the child worker. Passwords are not written to logs or reports.

Network / Meraki

API keys are stored using user-bound encrypted secret handling. For Meraki, the collector uses Bearer API authentication and shows authentication/API errors in Live Audit Status without displaying the key.

Storage

Storage supports API key only, Username + password (service account or root), and SSH service account + key/agent where supported. Legacy Storage auth labels remain compatibility aliases only.

Audit modules - step by step

Each technical module should be configured and tested independently before a Full run. The following sequence minimizes troubleshooting ambiguity.

1. Active Directory

1. Set Domain Name.
2. Load an authorized audit credential.
3. Open Active Directory and run the assessment.
4. Confirm the status identifies the domain controller being queried.
5. Review identity, privilege, account-policy and directory evidence.

2. Group Policy

1. Confirm Domain Name and credential.
2. Run Group Policy.
3. Review GPO inventory, security settings, inheritance and evidence gaps.

3. Servers - Windows

1. Enter Server IPv4 subnets in Settings, one /24 per line. Explicit server targets may also be supplied.
2. Load the Windows administrative audit credential.
3. Leave Linux disabled if this is a Windows-only assessment.
4. Run Servers.
5. The collector discovers responsive Windows-management candidates before credentialed collection.
6. WinRM, CIM/DCOM, WMI, WinRM PowerShell and SMB collection paths are used as applicable.
7. Non-Windows endpoints and nonresponsive addresses do not become Windows compliance failures.
8. Review Target-Discovery.csv, canonical Windows evidence, patch cohort evidence, and NO_DATA items such as REMOTE_AUDIT_BLOCKED.

4. Servers - Linux

Linux is opt-in. Enable Linux Server Assessment only when Linux servers are in scope and the SSH identity/key is configured. When disabled, Linux must not appear as a waiting collector or be probed by the Servers/Full workflow.

5. Network

1. Select the vendor/profile in Settings.
2. Configure the controller, management endpoint, device list, or cloud/API mode required by that vendor.
3. Store the API key or SSH credential in the encrypted secret field.
4. Run Network and watch Live Audit Status for secret-loaded, authentication, HTTP/API, device and objective progress.
5. Review per-device evidence and NO_DATA gaps separately from actual FAIL findings.

6. VMware

1. Configure vCenter and credentials.
2. Confirm required PowerShell runtime and PowerCLI/VCF.PowerCLI module availability.
3. Run VMware and review inventory, security configuration and TLS/permission limitations.

7. Storage

1. Open the Storage profile editor.
2. Add one storage device per grid row.
3. Select vendor, management address and authentication mode.
4. For API-key authentication, choose API key only; owner/account metadata is optional.
5. For private/self-signed management certificates, use the per-device read-only TLS exception only when explicitly approved. The invalid-certificate finding remains visible.
6. Save Settings, reopen the profile to confirm persistence, then run Storage.
7. Review management encryption, authenticated inventory, at-rest encryption, data-plane encryption and collection gaps.

8. Backup

1. Select the backup vendor and collection mode.
2. Configure server/API targets and encrypted credentials.
3. Run Backup and review jobs, repositories, sessions, encryption and recoverability evidence as available.

9. Microsoft 365 / Entra

1. Confirm Microsoft Graph prerequisites and tenant authorization.
2. Run the cloud assessment.
3. Review identity, privileged access, security configuration and tenant evidence gaps.

10. Full Technical Assessment

Use Full only after the applicable individual modules have been validated. Full runs the configured scopes; unconfigured and out-of-scope collectors should be skipped rather than represented as failures.

Management workspaces and every tab

Live Audit Status

The status window shows only applicable collectors for the current run. Typical phases include STARTING, DISCOVERY, AUTHENTICATING, COLLECTING, COMPLETED, NO_DATA, ERROR and CANCELLED. For Servers, host-level progress shows discovery, authentication and completed/total counters. For Network and Storage, API/endpoint progress is shown without secrets.

Cancel Audit and Close Status

Close Status closes only the child status window and does not stop the assessment. Cancel Audit is different: it writes the cooperative cancellation marker for the actual run worker. If the worker remains active after approximately two seconds, the GUI terminates that retained worker PID/process tree. Cancellation is enforced before status rendering so a malformed or locked status file cannot block the hard stop.

Closing the application while an audit is active also attempts to stop the active worker so it is not orphaned.

Result meaning

Evidence, lineage and integrity

Each run creates a dedicated evidence package. Technical evidence is organized under ISO reference folders where applicable, with consolidated reports and lineage identifying module, test, asset, collection time, collector version and mapping context.

Immutable evidence manifests hash stable technical evidence, reports, CSVs, screenshots and other package artifacts. Mutable runtime control files are intentionally excluded because they can change after manifest creation:

.audit-progress.json
.audit-status.jsonl
.audit-cancel.request
.worker-process.json
04-Logs/ISO27001-Audit.log

This prevents a successful run from invalidating its own evidence hash when final status/progress/log entries are written.

Reports and auditor use

Use Evidence & Reports to open completed runs. Review technical conclusions together with pass/fail estimates, confidence, raw evidence, evidence gaps and manual/governance records. A technical result without the required context should remain a technical observation, not be elevated automatically to an organizational compliance conclusion.

Guided Audit, SoA and governance

The Guided Audit provides 18 persistent evidence-gathering steps. The governance workspace covers Clauses 4-10, a 93-row Annex A Statement of Applicability, risk/treatment, internal audits, management review, corrective actions, evidence requests, sampling, KPIs and evidence freshness. Use these records to connect technical evidence to the broader ISMS rather than treating infrastructure checks as the whole audit.

Applicability and scoping rules

• Server subnets are isolated from Network scope.
• Windows assessment omits non-Windows systems rather than marking them failed.
• Nonresponding raw addresses remain discovery evidence and are not compliance failures.
• Linux is OFF by default and is omitted entirely when disabled.
• VMware, Storage, Backup, Network, AD/GPO and Entra use their own configured scope.
• Unselected/unconfigured collectors should not create NOT RUN noise in technical findings.

Troubleshooting quick reference

File > Documentation

The application File menu provides the maintained documentation set: Complete User Guide, Installation & Prerequisites, Configuration Guide, Network & API Guide, Storage & TrueNAS Guide, Backup Guide, Guided Audit Guide, IT Audit Workbench Guide, ISMS Governance Guide, Auditor Preparation Guide, Feature/Button Reference, and Troubleshooting Guide.