Drupal SOC 2 and ISO 27001 hosting controls

Which SOC 2 and ISO 27001 controls a Drupal platform team can evidence

A Drupal site inside an audited service or certification scope gives the platform team evidence for some controls and none for others. Drupal helps evidence patch timeliness, configuration-based change management, and parts of logging and backup, because the core and contributed modules publish advisories and releases on a known schedule, site configuration can be exported to version control, and the database, files and logs can be captured on a routine. It does not evidence access reviews, incident handling, vendor oversight or whether your processes actually run, because those are operating decisions made by your organization. SOC 2 is assessed against the AICPA 2017 Trust Services Criteria, with common criteria CC1 to CC9 applying to every report, while ISO/IEC 27001:2022 is assessed against the controls in its Annex A, so the same Drupal evidence is mapped to different control identifiers for each framework.

Start by mapping your Drupal evidence to the criteria or Annex A controls that your auditor will test. Under SOC 2, the logical access and change management criteria in CC6 and CC8 are the usual homes for role reviews and configuration export records. Under ISO/IEC 27001, the technological controls in Annex A and the change and vulnerability controls in the organizational theme are the usual homes. Confirm the exact control mapping with your auditor or certification body before you build the evidence set, because the mapping depends on your system boundary and on the points of focus your auditor applies. DeployOpen can prepare the systems, configuration and evidence that support these controls, but it does not issue SOC 2 reports, attestations or ISO certificates. Those come from an independent CPA firm or an accredited certification body.

Mapping SOC 2 criteria and ISO 27001 Annex A controls to Drupal capabilities

This table pairs each SOC 2 criterion or ISO 27001 Annex A control area with the Drupal capability that supports it and the configuration an assessor will expect to see. Read each row as a starting point for your own control design, because the criteria describe outcomes and the platform only supplies part of the evidence. Points of focus in the SOC 2 criteria are guidance for designing controls, not separate requirements, so you choose which ones your system needs.

Requirement	Drupal capability	Configuration needed
CC6 logical access: restricting access to systems and data to authorized users	Role system with permissions per role, and user account status controls for blocking accounts	Define roles by job function, remove the default administrator role from routine staff, and restrict Drupal administrator access to named, approved accounts
CC6 logical access: authentication for workforce users	Contributed SAML Authentication (samlauth) and OpenID Connect modules let an external identity provider handle sign-in	Route staff sign-in through your identity provider, confirm the module version supports your Drupal release, and disable local password login for staff roles where your design allows
CC7 system operations: detecting and responding to vulnerabilities	Drupal Security Team advisories with CVE identifiers and risk scores, released on security release Wednesdays	Subscribe to advisories for core and every contributed module in use, record the date each advisory was received and applied, and track exceptions with an approved reason
CC7 system operations: timely patching against security advisories	Core bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, per the core release schedule	Agree a patch window that accounts for these release days, test updates in a non-production environment with the same modules, and keep a dated record of each deployed update
CC7 system operations: keeping the platform supported	Drupal 10 reaches end of life on December 9, 2026, Drupal 11 is current, and Drupal 12 requires PHP 8.5 or later	Confirm the PHP and database versions in use against the Drupal version requirements, and document the upgrade plan and owner for any version approaching end of life
CC8 change management: authorizing and testing changes before production	Configuration management through exported configuration files that can be reviewed and deployed through version control	Commit configuration exports to Git, require review of changes before merge, block direct configuration edits on production, and retain the approval record linked to each release
A1 availability: maintaining capacity and recovering from failure	Backups and recovery depend on the database, files directory and code build, all managed outside core Drupal	Schedule database and files backups, store copies off the primary host, and run a documented restore test on a schedule your team sets and records
ISO 27001 Annex A technological controls: logging and monitoring of user and admin activity	Core Dblog and the contributed Syslog module record events, and web server and database logs sit outside Drupal	Route Drupal and web server logs to a central store, set retention that your policy defines, and restrict who can alter or delete audit records
ISO 27001 Annex A organizational controls: documented roles, responsibilities and access reviews	Role assignments and user lists can be exported and compared against HR or identity records	Run periodic access reviews of Drupal roles and administrators, record the reviewer and decision, and remove access for leavers and role changes

What evidence auditors will ask the platform team to produce

Auditors test whether controls worked over time, so the platform team needs dated records rather than descriptions of intent. The six streams below map to the Drupal hosting tasks an examiner is most likely to sample, and each one should be kept in a form that can be pulled for a chosen period.

Patch timeliness against advisories

Keep a dated log of every Drupal Security Team advisory that affects your core version or installed contributed modules, with the CVE identifier, the risk score and the date your team applied the fix. Drupal security releases land on the third Wednesday of the month, so the log should show whether each fix went out in your normal window or was handled as an exception. Ask your team to confirm how advisories reach them, because a missed notification is the most common gap an examiner finds in this stream.

Access and role reviews

Export the list of Drupal user accounts and their assigned roles at set intervals, then record who reviewed them, what was removed and why. Include administrator accounts, service accounts used by integrations and any SSO-linked users, since an identity provider can grant access that Drupal never shows as a password. Confirm with your identity team how account deprovisioning reaches the site, because a departed employee who still holds an active Drupal account is a finding in its own right.

Configuration export history as change records

Store each configuration export from the production site in version control, with the commit, author, reviewer and linked ticket. The commit history then serves as the change record for site structure, permissions and module settings, while content changes are covered by separate evidence. Check that production configuration is changed only through the reviewed path, because a direct edit in the admin interface that never returns to version control breaks the link between recorded change and running system.

Backup and restore test records

Keep backup job logs for the database and the file system, including the public and private file directories, and keep dated records of restore tests performed in a separate environment. A backup that has never been restored is weak evidence, so the restore record should name the backup restored, the environment, who ran it and whether the site returned to a working state. Confirm the retention period for backups with your own policy, since no default should be assumed.

Logging and log retention

Collect web server, Drupal watchdog and database logs in a central store, and document the retention period your organization has set for each source. Examiners usually ask for samples from a stated period, so confirm that logs for administrative logins, permission changes and failed authentication are captured and can be searched by date. Check that log access is itself restricted and recorded, because logs an administrator can silently edit are not reliable evidence.

Type 1 and Type 2 timing

A SOC 2 Type 1 report describes the system and whether controls were suitably designed as of a single date, while a Type 2 report adds an opinion on whether those controls operated effectively over a period. For a Drupal platform this means the patch, review, change and backup records above must exist continuously across the whole observation window, not only at the start. Ask your auditor which report type you need before the evidence collection begins, because the two require different amounts of history.

How SOC 2 and ISO 27001 frame the Drupal evidence differently

A SOC 2 examination is performed by a CPA firm and reports on the controls relevant to the Trust Services Criteria in scope. Security is always in scope through the common criteria CC1 to CC9, and availability, processing integrity, confidentiality and privacy are added only when the organization includes them. The starting point is management's description of the system, prepared against the AICPA's description criteria, which lists the Drupal components, hosting environment, data flows and the subservice organizations the platform relies on. A Type 1 report covers the design of controls as of a date. A Type 2 report adds an opinion on operating effectiveness over a period, so evidence has to exist continuously. Because the examination is assertion-based under AT-C section 205, management provides written representations to the auditor.

System description: Document the Drupal sites, hosting, database, backups and identity sources as they actually run, not as the design intends.
Type 1 or Type 2: A point-in-time design review suits a first report; a Type 2 needs logs and reviews that show controls operating across the period.
Management representations: Leadership signs statements about the system and controls, so the platform team must confirm each one before the letter is issued.
Report use: A SOC 2 report is generally restricted in use, while a SOC 3 covers the same categories in less detail for general distribution.
Criteria mapping: Map each Drupal control to the relevant common criteria, such as CC6 for logical access and CC8 for change management.

Before engaging a CPA firm, confirm which categories are in scope and whether the report will be Type 1 or Type 2.

How patch, config and backup evidence flows from Drupal to the auditor

The evidence for patch timeliness starts outside your environment, when the Drupal Security Team publishes an advisory. Each advisory carries a CVE identifier and a risk score, and those two fields are the keys your team should record in its own change tickets. Security releases ship on the third Wednesday of the month, so the advisory date, the release you applied and the production deployment date should each be captured as separate entries. Ask your auditor which window they expect you to meet for high-risk advisories, and write that window into your patch procedure before the observation period begins. A Type 2 examination tests whether the control operated over time, so a ticket that links an advisory to a deployed fix is stronger evidence than a general statement that patches are applied monthly.

Configuration evidence is created when the team exports configuration from the staging site and commits it to version control. Drupal's configuration management stores the site's settings as YAML files, so the commit, its author, its reviewer and the merge into the production branch form the change record. Link each merge request to the change ticket and to the advisory when the change is a security fix. Keep the production deployment log separate from the repository history so an auditor can confirm that what was deployed matches what was reviewed. Confirm with your own deployment tooling how it records who ran the deployment and which commit was live at each point.

Backup evidence is only useful if a restore has been tested, so the sequence should include a scheduled restore into an isolated environment, with its result recorded against the backup set it used. Log the database dump, the file store and the configuration commit hash together so a restore can be reproduced from one reference. Logs from the web server, the Drupal dblog or syslog output, and the identity provider should flow to a central store with retention set by your policy. Agree with your auditor in advance which log fields and retention period they will sample, and check that the restore records and log exports are readable without access to the original server.

What Drupal and DeployOpen cannot provide for these audits

A Drupal platform can produce much of the technical evidence for SOC 2 or ISO/IEC 27001, but several controls sit outside the code and the hosting. The cards below mark where those responsibilities stay with your organization, its hosting provider and the independent assessor, and they name the operating records you must keep yourself.

Written policies and risk assessment

Neither Drupal nor DeployOpen can write the information security policies, the risk register or the statement of applicability your auditor or certification body will read. Those documents must describe how your organization actually runs the Drupal site, who approves changes and how risks to the platform are scored. Check that each policy names the Drupal roles, environments and owners that appear in your evidence.

Access review decisions and sign-off

Quarterly or periodic access reviews are management decisions. A report of Drupal users and roles can show who holds Administrator or content-approval rights, but only your managers can decide whether each account should keep them and sign the review. Keep the signed review, the removals it triggered and the ticket that closed each one.

Hosting provider controls and reports

Where your Drupal site runs, whether in a cloud account, a data center or a managed platform, the physical security, host patching and datacenter controls belong to that provider. Ask each hosting provider for its own SOC 2 or ISO/IEC 27001 report and its bridge letter, and confirm which of your controls depend on it.

The auditor's or certification body's opinion

DeployOpen prepares systems, controls and evidence for an assessment, but it does not issue audit reports, attestations or certifications. A SOC 2 opinion comes from a CPA firm, and ISO/IEC 27001 certification comes from an accredited certification body. Agree the audit scope, sample period and evidence format with that body before collecting records.

Drupal 10 end of life and upgrade planning

Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule, so security releases will stop for sites still on it. An auditor will ask how you keep patching timely across that date. Plan the move to Drupal 11, which requires PHP 8.3 or later, as a dated change with its own change record and test evidence.

Contributed modules without advisory coverage

The Drupal Security Team publishes advisories for core and contributed projects, but a contributed module that is abandoned or not covered by a security advisory may leave a gap your patch process cannot close. Maintain an inventory of every contributed module and its maintenance status, and decide in writing how you will replace, fork or remove any module that stops receiving fixes.

Configuring a Drupal platform for SOC 2 or ISO 27001 evidence

This sequence sets up the Drupal platform so that each control an auditor will sample has a named owner, a repeatable routine and a dated record. Most of the evidence comes from routine operation, so the steps focus on what the team does every cycle and what it writes down.

Define the in-scope system and boundary
The platform team, with the control owner and the compliance lead, lists every component that stores, processes or transmits customer data for the service in scope. That list covers the Drupal codebase, web and database servers, file storage, the CI pipeline, hosting accounts and any third-party services the site calls. The team records the boundary as a system description, which is the document a SOC 2 examination or an ISO/IEC 27001 certification body will read first. The step is done when the component list is signed off and each item has an owner.
Pin a supported Drupal and PHP version
The team confirms which Drupal core version the site runs and checks that version against the Drupal core release schedule, then confirms the PHP version against the Drupal.org PHP requirements. A version that has reached end of life cannot produce a patch record that an auditor will accept as timely. Sites still on Drupal 7 are outside security support, so any extended support arrangement must be documented as a compensating control. The record is a version register showing Drupal core, PHP, database and web server versions with their support end dates.
Subscribe to advisories and set a patch routine
The team subscribes the platform owners to Drupal Security Team advisories and writes a patch routine that follows the cadence in the core release schedule: bugfix releases on the first Wednesday of each month and security releases on the third Wednesday. Each advisory is logged with its CVE identifier, risk score, affected projects, the date it was received and the date the fix reached staging and production. The routine should also cover contributed modules, because advisories apply to them as well. The evidence is a patch log that shows timeliness for each advisory, with exceptions and approvals recorded where a fix was deferred.
Record role and permission reviews
The team exports the list of Drupal roles and their permissions, along with user accounts and their assigned roles, and compares them with the access approved by the system owner. Administrative roles and accounts that can change configuration or install modules get separate review. Inactive accounts are disabled and the change is logged. The review is repeated on a schedule the team sets and approves, and each review is signed by a reviewer who is not the account holder. The record is a dated access review with the list reviewed, the decisions made and the removals completed.
Put configuration under version control
The team stores the Drupal codebase, including Composer files and custom modules and themes, in version control, and uses configuration export to capture site configuration as files. Production configuration changes are made in a non-production environment, exported, committed and deployed through a reviewed merge request, so that the repository is the change record. Direct edits on production are restricted or detected and then reconciled. The output is a change history in which each deployment links to a reviewed commit, an approver and a release, which is the core evidence for change management.
Define and test backup and restore
The team sets backup scope for the database, the files directory and the configuration, and documents how each is encrypted, where copies are kept and who can access them. A restore is run into a separate environment on a schedule the team sets, and the result is recorded: the time taken, the data checked and any gaps found. A backup that has never been restored is weak evidence, so the restore test is the item an auditor is most likely to sample. The record is a restore test report signed by the operator and reviewed by the control owner.
Centralize logs with defined retention
The team sends web server, Drupal and database logs, along with authentication events such as sign-ins, failed logins and permission changes, to a central log store that the application team cannot edit. Retention periods are set by the compliance owner and written into the control description, and access to the log store is limited and reviewed. The team tests the pipeline by generating a known event and confirming it appears in the store. The evidence is a logging standard, a retention setting and a test record showing that the events needed for review are being captured.

What SOC 2 and ISO 27001 readiness on Drupal involves

Does installing Drupal make a site SOC 2 or ISO 27001 compliant?

No. Drupal is open-source software, and no software product makes an organization compliant on its own. SOC 2 examines the controls an organization runs across its whole service, and ISO/IEC 27001 certifies an information security management system that the organization operates. Drupal supplies features and logs that help, such as role-based permissions, configuration export and an active security advisory process, but the policies, owners, reviews and records around those features are the organization's responsibility. Independent auditors and certification bodies decide whether the controls meet the standard, and DeployOpen prepares systems and evidence for that assessment without issuing any report.

How long does SOC 2 or ISO 27001 readiness on Drupal take?

No fixed duration applies to every site, and the effort depends on scope and on the records that already exist. The main drivers are how many systems and environments fall inside the boundary, whether patching, access reviews and change approvals already leave a trail, how many contributed modules and hosting providers are involved, and whether the organization is aiming for a Type 1 or Type 2 report or an ISO certification cycle. A team that already runs a documented patch routine and ticketed deployments will usually need less build work than one starting from undocumented manual changes. Ask any partner to show how the scope and milestones map to these drivers before accepting a timeline.

What does the internal team need to provide for a readiness project?

The team must supply the facts about the platform and the people who run it. Expect to provide:

A system description covering the Drupal sites, hosting, databases, file storage, backups and third-party services in scope
Named owners for access approval, patching, backups and incident response
Access to the existing repositories, deployment pipeline, logging and ticketing systems
Written policies the organization already uses, even if they are informal and need revision
Decisions from management on which trust categories or ISO controls apply to the service

Without these inputs, any partner will spend most of the effort reconstructing history instead of building controls.

Can our own platform team do SOC 2 or ISO 27001 readiness in-house?

Often yes, if the team has time, someone who understands the audit criteria, and the authority to change deployment and access processes. The work includes mapping controls to Drupal practices, defining evidence for each control, running the first review cycle and fixing gaps before an auditor arrives. Teams that lack an assessor's view of the criteria, or that are already carrying a heavy release schedule, often bring in an outside partner for the design and evidence review while keeping operational ownership internal. Either way, the auditor is independent of whoever prepares the evidence, so the organization should plan for that separation from the start.

What should a quote for Drupal SOC 2 or ISO 27001 readiness include?

A written quote should follow from a written scope and list each deliverable separately. Ask for the following items:

The systems, environments and Drupal sites inside the boundary, with any exclusions stated
The controls or criteria covered, referenced by their IDs in the framework
Which evidence will be produced, in what format and how often it recurs
The work for patch timeliness, access and role reviews, change management, backups and logging, each with its owner
Assumptions about existing records, client-side reviews and auditor coordination
Whether ongoing support, testing or retainer work is included or quoted separately

DeployOpen fixed-scope engagements are agreed in writing before work starts, so compare quotes on the same written scope.

How does a SOC 2 Type 1 report change the readiness work compared with Type 2?

A Type 1 report covers the system description and whether controls are suitably designed as of a single date, while a Type 2 report also covers whether those controls operated effectively over a period. Type 1 work therefore centers on design: documented procedures, configured Drupal roles, a defined patch process and a clear change path. Type 2 work adds the need for consistent operating evidence across the examination window, such as completed access reviews, dated patch records, restore tests and change approvals. Because a Type 2 examination depends on sustained operation, the recurring effort is usually larger, and the organization should confirm the period and report type with its auditor before setting the evidence plan.

Which Drupal controls produce evidence for patching, access, change and backups?

Each area produces different records. Patch timeliness depends on tracking the Drupal Security Team advisories, which arrive on the third Wednesday release window, and recording when each affected core or contributed project was updated. Access and role reviews use the user and role configuration in Drupal, exported and compared at each review. Change management can be evidenced through configuration export, where the config/sync directory is committed to version control and each deployment is linked to an approved ticket. Backups need recorded schedules, retention settings and restore tests, and logging needs central collection of Drupal watchdog or syslog events. Confirm with the auditor which of these records the criteria or controls require.

Confirming the current control versions and certifier rules before you start

Before you define scope, confirm with your auditor or certification body which control set and transition rules will apply to your assessment. For SOC 2, the examination is built on the AICPA's 2017 Trust Services Criteria in the version with revised points of focus published in 2022. Ask the auditor to confirm which of the five categories (security, availability, processing integrity, confidentiality and privacy) are in scope, because that choice decides which criteria your Drupal controls must map to. Ask also whether the description criteria your auditor expects are the 2018 version with 2022 implementation guidance, since your system description is evaluated against them.

For ISO/IEC 27001, confirm which edition your certification body will audit against. The 2022 edition restructured Annex A into 93 controls in four themes, and the transition period for the 2013 edition ended on 31 October 2025 under IAF MD 26:2023. Ask the certification body how it maps the 2022 Annex A controls to your Drupal platform, and whether the 2024 climate change amendment changes anything for your organization's context. Keep in mind that ISO does not certify organizations; accredited certification bodies do, so the questions go to them, not to ISO.

Accreditation rules also changed in 2026. Since 1 January 2026, Global ACI has assumed the roles of IAF and ILAC, and certification bodies must apply ISO/IEC 27006-1:2024 to all clients by 31 March 2026. Confirm that your chosen certification body holds current accreditation and check the certificate in the IAF CertSearch database, as ISO's certification page recommends. Also check the AICPA's proposed attestation standard revisions, which were exposed in February 2026 and would apply to engagements beginning on or after 15 June 2029 if adopted, so your evidence plan does not assume rules that may change.

How DeployOpen scopes and prepares Drupal compliance evidence

DeployOpen plans, builds, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Drupal hosting controls, we work from the evidence your SOC 2 or ISO/IEC 27001 assessment will ask for, then shape the platform so that evidence is produced as a normal part of operating it.

How we scope

Engagements are fixed-scope, with the controls, environments and sites in scope agreed in writing before work starts.
We confirm which Trust Services categories or Annex A control areas your assessor expects, so the build targets the right evidence.
The written scope names the Drupal versions, hosting layers, backup targets and logging sources that the work will cover.

How we build

We configure patch intake against Drupal Security Team advisories and document the internal timeline for applying each release.
We set up configuration export through version control so every production change can be traced to a reviewed commit.
We configure role definitions, backup jobs and log forwarding, then test restores and log retrieval before handover.

How we hand over

You receive runbooks, control descriptions and evidence procedures that your team and your assessor can follow.
Access review and change records are delivered in a format agreed during scoping, with the samples your team will repeat.
We document what the platform does and what remains with your organization, so ownership of each control is explicit.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so evidence keeps being produced after launch.
We can review evidence samples before your assessment period closes, so gaps are found while there is still time to fix them.
Your assessor and certification body make the final determination; we prepare the systems, controls and records they examine.

Drupal hosting controls for SOC 2 and ISO 27001