Open source CMS for US federal websites and Section 508

The system security plan (SSP) is the document that describes the system boundary, its impact level, and how each selected control is implemented. The contractor writes it for the hosting boundary, and each control implementation statement names the component that satisfies the control, such as the hosting provider's access controls, the Drupal or WordPress role model, the logging pipeline, or the patch process. Agencies and assessors read these statements first. The baseline is chosen under the NIST SP 800-53B low, moderate or high baselines, and the statements must match what the deployed system actually does. Confirm with the agency's authorizing official which baseline and templates apply, because the required format and the level of detail vary by agency and by the authorization path.

Agencies expect a conformance report, usually in the Voluntary Product Accessibility Template format or an equivalent, that states for each WCAG success criterion whether the site supports, partially supports or does not support it, with remarks and the test method used. The Revised 508 Standards incorporate WCAG 2.0 at Level A and AA, so the report should map results to both sets. WCAG 2.2 adds nine success criteria, such as 2.4.11 Focus Not Obscured (Minimum) and 2.5.8 Target Size (Minimum), and agencies increasingly request them. The report is written from testing, not from the CMS vendor's claims. Confirm with the contracting officer whether the agency requires WCAG 2.2 in addition to the 508 mapping.

The release pipeline produces automated scan output on every build and manual test records on each release candidate. Automated checks run in continuous integration against templates and key pages and store the rule ID, page, element and result in a report artifact. Manual records cover keyboard navigation, screen reader testing with named assistive technologies, focus order, and forms with error handling. Each release keeps the test scope, the tester, the date, the build version and the defects opened and closed. Automated tools find only part of the issues, so assessors look for manual evidence and for a documented remediation backlog. Ask the implementation partner to show a sample release record before the contract is signed.

Vulnerability scan records are produced by scanners run against the hosting boundary, the CMS application, and the operating system and database layers, with results saved with the scan date, scope and findings. Where criminal justice information is involved, the FBI CJIS Security Policy version 6.1, which took effect on June 26, 2026, requires vulnerability scanning at least monthly under the RA-5 control family. Authenticated scans are more useful for assessors than unauthenticated scans, because they show package versions. The contractor should keep scan history, risk ratings, remediation dates and documented exceptions. Confirm with the agency whether CJI is in scope, since that determines the minimum scan frequency for the boundary.

Patch records are produced by the update workflow, which logs each core and module release applied, the version before and after, the date, the approver and the test result in staging. Drupal publishes bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, and WordPress maintains only the most recent release in each series. Records should therefore show the version deployed, the advisory it addresses and the elapsed time from release to production. Drupal 10 reaches end of life on December 9, 2026, so the record should also show the upgrade path. Confirm the agency's required patch window, because it is written into the contract and the system security plan.

Assessors ask for evidence that backups run, that they are encrypted and stored inside the authorized boundary, and that restores have been tested. The record includes backup job logs, retention settings, encryption method, the date and scope of each restore test, and the time taken to restore the database, files and configuration. Restore tests should use the same Drupal or WordPress version and a representative data set, and the result should be compared with the recovery targets written in the contingency plan. Where cryptographic protection is required, the encryption must meet the agency's standard, such as FIPS-validated modules for CJI. Confirm the recovery time and recovery point targets with the agency, because DeployOpen cannot set them for the agency.

Change records are produced by the change management process and show what changed, why, who requested it, who approved it, what was tested, and when it was deployed. Each record links to the ticket, the code or configuration commit, the test results, and the rollback plan. Changes to the hosting boundary, the authentication configuration such as SAML or OpenID Connect settings, and the theme or templates each need their own entry. Assessors compare change records against the configuration baseline to confirm that undocumented changes did not reach production. The contractor and agency should agree the approval roles in writing before go-live, and the records should be retained for the period the agency requires.

Assessors use the assessment procedures in NIST SP 800-53A Rev. 5, which give determination statements for each control and describe examine, interview and test methods with suggested assessment objects. In practice, examine means reviewing documents such as the SSP, scan reports and change records. Interview means asking the people who operate the system how it works. Test means observing a control in action, such as a restore or an access review. Contractors should prepare evidence that fits each method, so that the records can be examined, the operators can explain them consistently, and the tests can be repeated. Ask the agency which assessment procedures and test scope its assessor will use before the assessment begins.

The agency's team can produce the evidence if it has staff who run the hosting, the CMS and the testing, and if those records are kept as the work happens. Many agencies find the effort is in the continuous records rather than in one-time documents. DeployOpen prepares systems, controls and evidence for compliance assessments under fixed-scope engagements, and ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not issue audit reports, attestations or certifications, which independent auditors and the authorizing agency decide. Ask any partner which records they will hand over, in what format, and who keeps them after the engagement ends.

The main drivers are the number of themes and templates, the number of sites sharing one codebase, how many user types must sign in and through which identity method, the hosting boundary the agency requires, and how much compliance evidence the agency expects you to produce. Neither Drupal nor WordPress carries a license fee, so the cost sits in design, build, accessibility remediation, migration, hosting, and security maintenance. Ask for a quote that lists each of these as a separate line, marks which items are one-time and which recur, and states what the agency will supply. Vendor-specific fees, such as paid add-on modules or a managed hosting contract, should appear explicitly.

Duration depends on the written scope, which is the one input the buyer controls most directly. A single site with one theme and no new identity integration is a different job from a multi-site estate with a shared design system, a migration from an older platform, and a hosting boundary review. DeployOpen does not publish timelines; a fixed-scope proposal sets the phases, deliverables, and dates before work begins. Ask the proposal to show dependencies on agency approvals, accounts, and reviews, because those often set the pace more than build work does.

Expect to supply four kinds of people and access. A system owner makes scope and acceptance decisions. An accessibility reviewer confirms that remediation meets the agency's interpretation of Section 508 and WCAG. An identity team provides the directory, SAML or OpenID Connect settings, and test accounts. Hosting contacts grant access to the cloud account, data center, or network segment that forms the authorization boundary. Agree in writing on who signs off each deliverable and how long reviews take, so the schedule does not depend on informal availability.

Yes, provided the team has defined skills and a documented release process. Maintaining a federal site needs people who can apply core and contributed module updates, test accessibility on each release, manage content and templates without introducing regressions, and keep logs and change records that an assessor can review. Many teams start with DeployOpen for the initial build and accessibility baseline, then take over operations with a documented runbook. Ask any partner, including DeployOpen, to hand over runbooks, test scripts, and configuration in a form your staff can use without outside help.

No. DeployOpen plans, implements, hardens, documents, and tests systems and prepares the controls and evidence that an assessment will examine. It does not issue audit reports, attestations, authorizations, or certifications. Authorization decisions and independent assessments come from the agency's authorizing official and assessors, and any accessibility conformance claim is the responsibility of the owning organization. Ask a partner to show the evidence package it prepares and to state in the proposal which determinations remain with your agency.

Control selection starts with the system impact level and the baseline that matches it, then the team tailors that baseline to the actual CMS, hosting, and integration design. Typical areas include access control, configuration management, audit logging, patching and vulnerability scanning, and incident response for the hosting layer, plus the identity integration that signs editors in. Confirm with your agency's security office which baseline and overlays apply and which system boundary they assess. Ask the implementation partner to map each control to the component that implements it, so that inherited controls from a hosting provider are not counted twice.

Drupal core is licensed under GPL-2.0-or-later, and there is no paid edition of Drupal itself. WordPress is also open source, so the software itself carries no license fee. Procurement still has costs: build and accessibility work, hosting, backup, security maintenance, and any commercial modules or support contracts you choose. Some Drupal 7 sites that cannot migrate yet rely on paid extended security support from certified vendors listed by the Drupal Association, which is an optional recurring cost. Ask procurement to separate the software line from services and hosting so the comparison with licensed platforms is accurate.