Created Pages, Tables, and Stored Data
Purpose
This article explains what CMSSPM creates inside WordPress when it is installed and used. The goal is to give administrators a clear, high-level understanding of the plugin’s admin pages, supporting database structures, and the types of data it stores over time.
Where to find it
This article belongs in the Installation or Administration section because it helps explain the footprint of the plugin inside a WordPress site. It is especially useful for administrators who want to understand what is added to the environment before deployment to production.
Created admin pages
After activation, CMSSPM adds its Posture Management area to wp-admin. This provides the main interface for working with the plugin, including the Overview Dashboard and related security sections such as Core Security, Account Security, Browser Security, Email Security, File Security, and Settings.
These pages are administrative plugin screens, not public-facing site pages. In other words, CMSSPM does not create front-end content for visitors; it creates admin-side interfaces used to review findings, scoring, and plugin configuration.
Depending on the version and feature set, additional internal pages, subpages, or workflow views may also appear as the plugin grows.
Created tables and internal structures
CMSSPM may create one or more custom database tables, options, or internal data structures needed to support scanning, findings, scoring, settings, and historical tracking. These structures allow the plugin to store results in a way that is more reliable and queryable than relying only on temporary runtime data.
At a high level, this may include storage for:
- scan results,
- findings and their status,
- scoring-related values,
- plugin settings and preferences,
- history or audit-style records,
- mitigation state and related notes.
The exact table names and schema details should be documented separately in technical documentation. This overview article is only meant to explain the general purpose of that stored data.
What data is stored
CMSSPM is designed to retain the information needed to make the dashboard useful across time, not just during a single page load. That means it may store data such as:
- scan timestamps,
- finding identifiers and categories,
- result status values such as pass, fail, review, or mitigated,
- scoring inputs and score history,
- configuration choices,
- notes, justifications, or metadata attached to findings.
This stored information helps support repeat scans, score tracking, reporting, and operational review.
Mitigation-related data
When a finding is marked as mitigated, CMSSPM stores that state with the finding so it can be treated as passing for scoring purposes. The mitigation record also stores the user who applied it along with the note or justification entered at the time.
That mitigation remains associated with the finding until it is removed by an administrator. This creates a durable record showing that the finding was intentionally handled rather than simply ignored.
Why this data is kept
The plugin stores this information so administrators can work with security posture as an ongoing process rather than a one-time scan. Without stored findings, status tracking, and historical context, the plugin would not be able to provide meaningful scoring, trend visibility, or consistent operational workflows.
Keeping structured data also makes it possible to distinguish between newly discovered findings, previously reviewed findings, and findings that have been formally mitigated or resolved.
Notes and scope
This article is intended as a plain-English overview, not a schema reference. It does not list exact database table names, column definitions, retention rules, or uninstall behavior.
Those implementation details should be documented separately in technical documentation for administrators, reviewers, or developers who need a more precise understanding of the plugin’s storage model.