Architecture and Security

Architecture and Security

Platform Architecture

WISdom is a SaaS platform built on Microsoft Azure that uses a hybrid architecture to monitor, optimize, and manage SQL Server environments. Data collection occurs locally within your network, while processing, storage, and visualization are handled in the Fortified WISdom cloud.

This design means your SQL Servers are never directly exposed to the internet, and no agents are installed on your database servers.

Architecture Components

The WISdom platform consists of two primary components:

WISdom Data Collector (Your Environment)
The WISdom Data Collector is a lightweight Windows service that runs on a virtual machine (VM) in your network. It connects directly to your SQL Server instances using standard SQL calls, Windows Management Instrumentation (WMI), and Windows Performance Counters (PerfMon) to collect performance metadata, host metrics, and workload statistics. The data collector is agentless — it does not require any software to be installed on the monitored SQL Server instances themselves.

Each data collector can monitor multiple SQL Server instances, and organizations can deploy multiple data collectors across different network segments or regions for distributed collection. For sizing guidance, see Collector Server Sizing.

WISdom Cloud (Microsoft Azure)
The WISdom Cloud is the processing and storage layer of the platform. It receives encrypted data from your data collectors, processes it through the WISdom analytics engine, and stores it in your organization’s dedicated Azure database. The WISdom web application at app.fortifiedwisdom.com provides access to dashboards, analytics, alerting, and the WISdom Advisor AI assistant.

Data Flow

The following steps describe how data moves from your SQL Server environment to the WISdom interface:

1. Collection — The WISdom Data Collector service queries your SQL Server instances using SQL calls, WMI, and Windows Performance Counters (PerfMon) at configured intervals, ranging from once per minute to once per month depending on the data type.
2. Compression & Encryption — Collected data is compressed and encrypted locally on the data collector machine using a unique encryption key pair assigned to that specific collector.
3. Transmission — Encrypted data is transmitted to the Fortified WISdom Azure API (collectorapi.fortifiedwisdom.com) over HTTPS every minute.
4. Processing — The Azure API authenticates the data collector, decrypts the payload, and processes the data through WISdom’s analytics engine.
5. Storage — Processed data is written to your organization’s dedicated Azure database. Each WISdom client has an isolated database — client data is never commingled.
6. Visualization — The WISdom web application reads from your dedicated database to render dashboards, analytics, scores, alerts, and recommendations.

Configuration updates flow in the opposite direction. When changes are made in the WISdom Admin Console (such as adding monitored instances or adjusting collection settings), those configuration updates are securely transmitted from the Azure API to the data collector using a dedicated certificate pair.

Connection Resilience

The WISdom Data Collector service continues collecting metrics even if the connection to the Azure API is temporarily unavailable. Collected data is written to files in the WISdom installation folder and queued locally until the connection is restored. Upon reconnection, the queued files are uploaded in an orderly fashion — older files are grouped into small batches and transmitted every minute until all data has been processed and is available in the WISdom interface. This ensures no monitoring gaps occur during brief connectivity interruptions.

Data Privacy Principles

WISdom is built on a minimal-collection philosophy. The platform collects only the operational and performance metadata needed to deliver database observability and FinOps intelligence. The following principles govern all data collection activity.

No Personally Identifiable Information (PII)
WISdom does not collect, store, or transmit any personally identifiable information. All captured data is limited to database engine metadata, system performance counters, and configuration settings. No end-user data, application data, table contents, row-level data, or business data is ever accessed or collected.

No Application or Business Data
WISdom never reads, queries, or extracts data from customer tables, views, or stored procedure result sets. The platform operates exclusively at the database engine and operating system metadata layer. Query text is captured for performance analysis purposes only and does not include result set data.

No Credential Storage
WISdom does not store database passwords, connection strings with embedded credentials, or authentication tokens in any collected dataset. Connection credentials used by the WISdom Data Collector are managed securely within the collector agent and are never transmitted to the WISdom cloud platform.

Minimal Collection Principle
WISdom follows a least-privilege, minimal-collection approach. The data collector requires only read-only access to system Dynamic Management Views (DMVs), catalog views, and operating system performance counters. No write operations are performed against customer databases under standard collection. The exception is Audit Events, which are configured on a per-instance basis at the client’s request.

For a complete inventory of every data point WISdom collects and how often, see the Data Collection Reference.

Data Collection

What Data Does WISdom Collect?

WISdom collects operational metadata across four categories from your database environment:

• Performance Metrics — CPU utilization, memory pressure, wait statistics, I/O throughput, and query execution statistics at the database engine level.
• Configuration Data — Instance settings, database options, server properties, and feature usage flags used to assess health and identify optimization opportunities.
• Capacity & Sizing Data — Database file sizes, disk utilization, table row counts, index statistics, and memory allocation used for capacity planning and cost attribution.
• Security & Compliance Metadata — Login enumeration, permission structures, encryption status, and audit configurations used to surface security posture and compliance readiness.

The WISdom Data Collector currently supports 100+ distinct data collection types across multiple database platforms. Data is collected at intervals ranging from every minute (real-time performance counters) to once per month (static configuration data), based on how frequently the underlying data changes. For the full collection inventory, see the Data Collection Reference.

These four categories map to two types of underlying data: metadata and workload data.

Metadata

Metadata describes the structure and configuration of your SQL Server environment. This includes:

• Host server names, operating system details, and hardware specifications (CPU, memory, storage)
• SQL Server instance names, versions, editions, and configuration settings
• Database names, schema names, and table names
• Index names, definitions, and usage statistics
• SQL Server Agent job definitions and execution history

Workload Data

Workload data captures the performance characteristics of your SQL Server environment. WISdom collects this information from SQL Server’s built-in system tables and Dynamic Management Views (DMVs), including:

• Query and procedure statistics — Execution counts, run times, CPU consumption, logical reads, and other resource metrics from sys.dm_exec_query_stats and sys.dm_exec_procedure_stats
• Active session data — Currently executing queries, wait information, blocking chains, and session-level resource usage from execution session DMVs (similar to the data surfaced by the well-known sp_whoisactive monitoring procedure)
• Query Store data — When Query Store is enabled on monitored databases, WISdom leverages this data for historical query performance analysis
• Blocking and deadlock data — Blocking chains, deadlock graphs, and contention events
• Resource utilization — CPU, memory, storage I/O, and performance counter data collected at the host and instance level

What WISdom Does NOT Collect

As outlined in the Data Privacy Principles above, WISdom operates exclusively at the metadata layer. Here’s the technical detail behind that commitment.

Because WISdom reads from SQL Server’s internal collections rather than running Extended Events (XE) traces, all query text is normalized by SQL Server before WISdom processes it. Literal values and parameters are generalized, which means:

• No personally identifiable information (PII) is collected or transmitted
• No application data or row-level content from your databases is accessed
• No credentials, connection strings, or secrets are gathered

WISdom collects only the system metadata and normalized workload statistics required to deliver monitoring, optimization, and cost analysis.

Collection Frequency

WISdom uses adaptive collection frequencies to balance data freshness with minimal impact on monitored systems:

For the complete list of all 100+ collection objects and their frequencies, see the Data Collection Reference.

Data Collection Method

The WISdom Data Collector uses three methods to gather data:

• SQL calls — Direct T-SQL queries against system tables, DMVs, and Query Store catalog views on each monitored instance. This is the primary collection method for workload and performance data.
• WMI (Windows Management Instrumentation) — Used to collect host-level information such as operating system details, hardware specifications, and server configuration data.
• Windows Performance Counters (PerfMon) — Used to collect real-time host and instance performance metrics that are not available through WMI, including CPU utilization, processor queue length, memory usage, page life expectancy, disk I/O throughput and latency, and network statistics. These counters can be viewed and graphed in the WISdom Performance module.

All three methods are read-only by default. The WISdom Data Collector does not write to, modify, or create objects on your SQL Server instances under standard collection.

The exception is Audit Events — when this optional feature is enabled at the client’s request, the data collector creates objects on the target instance (including a WISdom database, a SQL Server Audit, an XE session, and a SQL Agent job) to support audit event and deadlock collection. Audit Events are not enabled by default and must be configured in coordination with Fortified support on a per-instance basis. For details on the objects created and the data collected, see Audit Events.

Data Storage and Retention

Where Is Data Stored?

All collected data is stored in the Fortified WISdom Azure environment. Each WISdom client is assigned a dedicated Azure database, ensuring complete data isolation between clients. Only your organization’s authorized users and Fortified’s support team can access your data.

How Long Is Data Retained?

WISdom retains data at different levels of detail based on age. These retention periods are consistent across all WISdom clients:

Data Deletion Requests
Customers may request deletion of their data at any time by contacting their Fortified account team or emailing WISdomSupport@fortified.com.

Contract Termination
Upon contract termination, all customer data — including performance metrics, configuration snapshots, and alert history — is purged from the WISdom platform within 30 days.

Security

Encryption

All data is encrypted both in transit and at rest:

• In transit: Data transmitted between the data collector and the WISdom Azure API is encrypted using TLS 1.2 or higher over HTTPS.
• At rest: Data stored in the Azure environment is encrypted using AES-256 encryption through Azure’s encryption-at-rest capabilities.
• Collector-level encryption: Each data collector is assigned a unique parent/child encryption key pair. This key pair is used to encrypt all data before transmission and is automatically rotated weekly.

Client Isolation

Each WISdom client operates in a fully isolated data environment:

• Dedicated Azure database per client
• Unique encryption key pair per data collector
• Dedicated certificate pair for configuration communication
• Access limited to the client’s authorized users and Fortified support

Authentication and Access Control

WISdom supports multiple authentication methods:

• Okta-based authentication — Default authentication for WISdom user accounts
• Single Sign-On (SSO) — Integration with your organization’s identity provider via OIDC (OpenID Connect), including Microsoft Entra ID and Okta. See Entra SSO Setup and Okta SSO Setup for configuration details.

Within WISdom, role-based access controls provide three permission levels: Regular User, Power User, and Admin. See User Account Management for details.

Compliance

WISdom is SOC 2 Type II compliant. Fortified’s security controls, data handling practices, and platform availability have been independently audited and verified over a sustained evaluation period, confirming that controls are not only properly designed but consistently operating as intended.

WISdom’s data collection practices are designed to align with GDPR, HIPAA, and other major regulatory frameworks. The platform’s minimal-collection approach, encryption standards, client data isolation, and data deletion capabilities support compliance across regulated industries.

WISdom is also a FinOps Certified Platform — the only certified platform specifically designed for database environments.

Network Requirements

The WISdom Data Collector requires the following network access:

• Outbound HTTPS to collectorapi.fortifiedwisdom.com — for data transmission and configuration updates
• SQL connectivity to monitored instances — standard SQL Server ports (default 1433)
• WMI connectivity to monitored hosts — ports 135 & 49154 (or dynamic range 49152–65535 if unavailable)
• Windows Performance connectivity to monitored hosts — port 445

No inbound internet connections are required for your environment. For complete network and firewall requirements, see Installation Requirements.

Frequently Asked Questions

Does WISdom install anything on my SQL Servers?
No. WISdom is agentless. The data collector service runs on a separate VM in your environment and connects to your SQL Servers remotely using SQL calls, WMI, and Windows Performance Counters. The only exception is when Audit Events collection is enabled — in that case, specific objects are created on the target instance in coordination with Fortified support.

Can other WISdom clients see my data?
No. Each client has a dedicated, isolated Azure database. Data is never shared or commingled between clients.

Does WISdom modify anything on my SQL Servers?
Under standard collection, no — the data collector only reads from system tables, DMVs, and Query Store. However, if the optional Audit Events feature is enabled at your request, the data collector creates objects on the target instance (including a WISdom database, a Server Audit, an XE session, and a SQL Agent job) to support audit event and deadlock collection. This is configured on a per-instance basis in coordination with Fortified support.

Does WISdom access data inside my databases (row data, application data)?
No. WISdom only collects system metadata and workload statistics from SQL Server’s built-in system tables and DMVs. It does not read from user tables or access application data.

What happens if my data collector loses connectivity?
The data collector continues collecting metrics locally. Data files are queued in the WISdom installation folder and uploaded in orderly batches once the connection is restored. No monitoring data is lost during brief connectivity interruptions.

How do I know my data collector’s encryption keys are current?
Key pairs are rotated automatically every week. No manual intervention is required. If there is an issue with key rotation, the WISdom Admin Console will surface a collection error notification.

Related Pages

• WISdom Overview
• Installation Requirements
• Collector Server Sizing
• Collection Account Requirements
• Admin Console - Data Collectors
• Audit Events
• Data Collection Reference