Migrating from D2L Brightspace to Moodle: what the move involves
Course content moves through exports, while gradebook logic, learner history and integrations are rebuilt or archived. That is the short answer for most institutions and training teams leaving Brightspace, whether the trigger is a renewal, a licensing change, a data residency requirement or the wish to stop depending on one vendor. Course packages and the materials inside them can be carried across. The parts that depend on Brightspace's own engine, such as release conditions, calculated grades and the completion history stored in its database, have to be rebuilt in Moodle or kept as an archive that auditors and registrars can still read. Plan for those components first, because they decide the effort more than the number of courses does.
In most cases the institution's learning technology team, or the training function in a company, owns the project and brings in an implementation partner for the technical work: export tooling, Moodle installation and hardening, plugin selection, data mapping and cutover testing. The internal team keeps the decisions that only it can make, such as which programs run in parallel during a term, which grade history must stay reachable and who signs off each course. Ask the partner to show how it will handle the Brightspace Data Hub exports for grades, enrollments and activity, and how the identity and student information system feeds will be reconnected. Confirm with your own registrar and security team which records must be retained and for how long before any export starts.
Effort and risk are driven by three things: how much of the catalog depends on Brightspace-specific features, how many external tools are registered through LTI, and how tightly the SIS and single sign-on feeds are tied to the current LMS. The work is best scoped as a fixed project, with the course inventory, component mapping, rebuild list, archive design and cutover plan agreed in writing before any build begins. DeployOpen plans and runs this kind of work as fixed-scope engagements, with ongoing support available as a retainer afterwards. Moodle's own release schedule matters too: check which Moodle version you will deploy, its PHP and database requirements, and whether your web server points to the public directory, because that changes the installation steps.
Which Brightspace components move to Moodle cleanly and which need rebuilding
This table maps common Brightspace components to their closest Moodle equivalents and labels each as clean, needs rework or gap. Treat every label as a starting hypothesis, because Common Cartridge coverage varies by course, so confirm each row with a test export from your own Brightspace instance before you plan the cutover.
| Brightspace component | Likely Moodle path | Migration status |
|---|---|---|
| Course content and files | Common Cartridge or IMSCC import is the expected route; confirm which Moodle import path accepts your package and which file types and embedded media carry over | Clean for standard HTML and files, confirm embedded media |
| Quizzes and question banks | Quiz content may arrive as cartridge assessments, but question types, feedback and settings need checking against Moodle quiz and question bank structures | Needs rework |
| Discussions | Forum-style content is expected to map to Moodle forums, but thread settings, grading and group restrictions should be confirmed in a test course | Needs rework |
| Dropboxes and assignments | Assignment settings, due dates and rubrics must be recreated or checked; learner submissions stay in Brightspace and are not part of the course package | Needs rework |
| Gradebook and grade history | Grade items and final grades are not expected to migrate as live gradebook data; plan to export grades and rebuild grade categories in Moodle | Gap, rebuild and archive |
| Release conditions | Brightspace release conditions must be rebuilt using Moodle activity completion and restriction settings, then tested for each learner group | Needs rebuilding |
| Calculated grades and formulas | Formulas do not carry over as calculations; confirm the logic with the instructor and reproduce it with Moodle grade settings or documented manual steps | Gap, rebuild |
| Competencies | Confirm how your Brightspace competency frameworks map to Moodle competencies before migrating; the mapping is a design task, not a file transfer | Needs rebuilding |
| LTI tools and launch links | Each external tool needs a new registration in Moodle with its own keys and launch settings; confirm each tool supports LTI in your Moodle version | Needs rework |
| Data Hub reporting | Data Hub reports are Brightspace features; archive the CSV exports you need and plan replacement reports in Moodle or your reporting layer | Gap, archive first |
| Single sign-on and user accounts | Moodle core includes LDAP, LTI, OAuth 2 and Shibboleth authentication; confirm your identity provider and whether a SAML2 plugin is needed | Needs rework |
How the Brightspace to Moodle migration runs, step by step
The sequence moves courses, learner records and sign-in in controlled stages, so each stage produces a checkable record before the next one starts. By the end, Brightspace is switched off with its data archived and signed off.
Inventory courses, integrations and data sets
Your team lists every active and archived course, its export format, the quizzes, question banks, release conditions and calculated grade items it uses, and every integration that touches Brightspace, including the SIS feed, SSO, LTI tools and Data Hub reports. Confirm with D2L which export options your contract and version support, since course packages and Common Cartridge output differ in what they carry. The output is a component inventory that marks each item as survives, rebuild or retire.
Stand up the Moodle target environment
Install Moodle in your own infrastructure with the database, PHP version and web server layout required by the release you choose. Check the current support dates for that release in Moodle's release schedule before you commit, and point the web server document root at the public directory if you run Moodle 5.1 or later. The step is complete when a test course can be created, backed up and restored on that environment.
Run a pilot course migration
Choose one representative course, ideally one with quizzes, release conditions and a weighted gradebook, and import its export into Moodle. Rebuild each item that did not carry across, such as release conditions, calculated grades and question banks, and log the time and the manual fixes each one needed. The pilot rebuild log shows which patterns repeat across the catalog, so you can estimate rebuild effort from evidence rather than assumption.
Migrate the catalog and archive learner records
Batch the remaining courses by department or term and repeat the pilot process, checking each course against its inventory line. Export learner records from Data Hub as CSV files and store them in a separate, access-controlled archive with retention rules that your records officer approves, rather than loading full histories into Moodle. The output is a course-by-course reconciliation report listing each course's status, open issues and owner.
Run both systems in parallel
Keep Brightspace and Moodle running together for a defined period agreed with your academic or training leads, and reconcile enrollments, grades and content changes between them. Freeze new course edits in Brightspace only after instructors confirm the Moodle copy is authoritative for each course. The step closes when the reconciliation report shows no unresolved differences for any active course.
Cut over SIS and single sign-on
Point your student information system feed and enrollment sync at Moodle, and move sign-in from Brightspace's identity setup to Moodle's authentication plugins, such as LDAP, OAuth 2 or SAML2 through the SAML2 single sign-on plugin, as your identity provider supports. Test provisioning, de-provisioning and role mapping with a small set of accounts before opening access to all users. The step is done when a full enrollment cycle runs through Moodle without manual correction.
Decommission Brightspace with a signed-off archive
Confirm with D2L the contractual end date, data return terms and deletion obligations, then export the final course packages and Data Hub sets your records policy requires. Verify the archive by sampling restores and checking record counts against source reports, and obtain written sign-off from the data owner. Brightspace is switched off only after the signed-off archive and the cutover records are filed together.
Which data and integrations to export, archive and reconnect
Brightspace data falls into four groups: course content, learner records, identity and roster feeds, and external tools. Each needs a different export path and a different owner on the Moodle side, so plan them as separate workstreams before the cutover date is set.
Course packages in Common Cartridge format
Export course content from Brightspace as a Common Cartridge package and import it into Moodle as the starting structure for each course. Treat the package as content only: it carries modules, files, pages and some assessments, but not learner submissions or live grades. Confirm which Brightspace components your export includes, then rebuild release conditions, calculated grades and any LTI-linked activities by hand, because they do not come across as working logic.
Grades, enrollments and activity from Data Hub
Use Data Hub CSV exports to pull user-level data sets for grades, enrollments and activity history. These files are your source of truth for what learners did and what they were graded, so store them with the migration records. Check that each export covers the terms you must keep, and confirm with your records office how long the originals must be retained after the old tenant is closed.
Learner records archived outside Moodle
Keep completed-course transcripts, grade history and attempt data in an archive you control, separate from the live Moodle database. Historic records rarely need to be active in the new LMS, and loading them there complicates gradebook reconstruction. Ask your registrar or compliance lead which fields and retention periods apply, and test that an archived record can be read without Moodle running.
SIS roster feeds
Enrollments in Brightspace are often driven by a student information system feed. Rebuild that feed against Moodle, typically through the Moodle web services or an external database connection, and map course IDs, term codes and roles before any live roster is loaded. Run a trial feed with a small set of courses and compare enrollment counts against the SIS before switching the source for all terms.
Single sign-on through Moodle authentication
Moodle core ships authentication plugins for LDAP, OAuth 2, Shibboleth, LTI and other methods, so SSO is configured in the platform, not added later. Choose the method that matches your identity provider, and if you use SAML2, plan to install the SAML2 single sign-on plugin from the Moodle plugin marketplace. Test login, logout and account matching with real staff and learner accounts before the cutover.
LTI tools re-registered
Each external tool connected to Brightspace, such as publishers' content, proctoring or video services, must be registered again in Moodle with its own consumer key, tool URL and launch settings. Ask each vendor whether it supports the LTI version you will use and whether its licensing is tied to the old platform. Keep a register of tools, owners and test results so no integration is lost during the move.
Why release conditions and calculated grades must be rebuilt by hand
Conditional release rules and calculated grades are the parts of a Brightspace course most likely to behave differently after migration, so plan to rebuild them in Moodle rather than expect them to arrive intact in a Common Cartridge package. A cartridge carries course content, modules, links and many assessment items, but the logic that decides when a learner sees an activity and how a final grade is computed depends on the Brightspace gradebook and release engine. Confirm in your own export which of these structures appear in the package at all, and record what you find for each course before you start the rebuild.
Moodle handles these concepts with its own model: activity completion and restriction settings on activities and sections, grade categories with aggregation methods, and grade items with their own weights and scales. Brightspace grade schemes, weighted categories, drop-the-lowest rules and calculated items do not map one to one onto these settings, so each course needs a mapping sheet that lists every Brightspace rule, its Moodle equivalent and the owner who signed off. Pay particular attention to rules that depend on dates, group membership or the order in which items are released, because they are the first to break silently.
The acceptance test is reconciliation. For a sample of learners in each course, including some with late submissions, excused items and partial attempts, compare the final grade total and each category total in Brightspace with the same learner's totals in the migrated Moodle course, and check that each release condition shows or hides the same activities. Run the comparison on a staging copy with grade data loaded, not on a blank course, and do not cut over any course until every difference is explained and approved. Ask your Moodle hosting or implementation partner to document how the grade aggregation settings were chosen so the result can be defended during an audit.
How the migration changes by institution size and starting point
A university usually has many course shells, including inactive and duplicated courses from past terms, and a student information system that remains the authority for enrollments. The migration scope starts with a decision about which shells move at all. Archiving old terms in Brightspace or as Common Cartridge packages is often cheaper than moving every shell into Moodle. Enrollments should flow from the SIS into Moodle, so the SIS remains the source of truth during the transition.
- Shell triage: Classify courses as active, archive only, or discard, and agree the list with registrars and department heads before any export.
- Cutover order: Move a pilot set of active courses first, then the current term in one block, then the remaining catalog. Keep the SIS feed pointed at Brightspace until the pilot passes.
- Enrollment sync: Confirm how Moodle receives enrollments (for example, through an SIS-driven sync or an agreed file import) and test it with a term's worth of sections.
- Archive obligations: Keep grade and activity records from Data Hub exports under the institution's retention schedule, outside the LMS.
- Single sign-on: Plan the identity cutover so students and staff are not split across two login paths during the term.
Before committing, ask your registrar and records office to confirm retention rules for grades, transcripts and course records, and confirm the SIS integration method with your SIS vendor.
A school district usually manages shared rosters across many schools, with teachers who may teach in several buildings and with student records governed by state and local rules. Scope is driven by the roster source, which is often a district directory or SIS, and by how many teachers rely on shared course templates. Cutover must keep class rosters accurate for each term, so changes happen at term boundaries whenever possible.
- Roster source: Decide which system provides class and teacher assignments, and build Moodle enrollment from that source rather than from manual lists.
- Shared templates: Rebuild shared course templates once in Moodle, then copy them per school, instead of moving each teacher's copy.
- Cutover timing: Schedule the switch for a break between terms, so no class loses access mid-unit.
- Student data archive: Export learner records and grade histories before the Brightspace contract ends, and store them under district retention policy.
- Access for guardians and staff: Confirm which accounts need access during the transition and which roles need to change in Moodle.
Ask your district's privacy officer which student records must be retained and where, and confirm the roster integration method with your SIS provider before scheduling any cutover.
A corporate training team often has fewer courses than a university but more compliance weight on each one. Completion records may be needed for audits, regulatory evidence or contract obligations, and the people who must be trained may change roles often. The scope therefore centers on learner records and proof of completion, not only on course content. Course content can usually be moved, but the completion history has to be exported and retained separately.
- Compliance course inventory: List every course that carries a regulatory or contractual requirement, and treat those courses as the first to verify.
- Record archive first: Export completion and assessment history before cutover, and confirm the export includes the fields your auditors need.
- Cutover order: Move low-risk onboarding courses first, then compliance courses once records are archived and verified.
- Rebuilt logic: Recreate release conditions, prerequisites and completion rules in Moodle, and test each one against a sample learner.
- Evidence of control: Document the migration as a controlled change, with dated test results, so auditors can see what moved and when.
Ask your compliance lead which training records must be kept for how long, and confirm with your auditors how they expect migrated completion evidence to be presented.
What Moodle 5.1 and 5.3 require from your hosting
Choose the Moodle release before you size the servers, because the two candidates have different hosting floors. Moodle 5.1 requires 64-bit PHP 8.2 or later, with PHP 8.3 and 8.4 supported, and it runs on PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or Microsoft SQL Server 2017 or later. Moodle 5.3 raises the floor to 64-bit PHP 8.3 or later (8.4 supported), PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. If your database server is older than these floors, the database upgrade is a separate project that belongs in your plan and budget, not a footnote to the Moodle install.
The upgrade paths are also version-specific. A site must already be on Moodle 4.2.3 or later to upgrade to 5.1, and on Moodle 4.4 or later to upgrade to 5.3. Brightspace migrations often start from a fresh Moodle install rather than an upgrade, but if you plan to move an existing Moodle site as well, confirm its current version first. Support windows also differ. Moodle 5.1 has general support until 5 October 2026 and security support until 19 April 2027. Moodle 5.2 has security support until 4 October 2027. Moodle 5.3 is the next long-term support release, with general support until 4 October 2027 and security support until 1 October 2029. Pick the release that matches the support calendar your institution can keep, and confirm each date on the Moodle releases page.
From Moodle 5.1, the web server document root must point to the new /public directory rather than the main Moodle folder. Pointing it at the wrong folder can expose directory listings or produce errors, so set the virtual host and reverse proxy configuration during build, not at cutover. Before the build is frozen, read the Moodle 5.1 release notes and the Moodle 5.3 release notes for the exact PHP extensions and database settings, and confirm them against the hosting images you intend to use. Treat those notes as the authority for version floors, since the release schedule can change.
What drives migration cost and duration, and how to keep each down
This table lists the components of a Brightspace to Moodle move, who is paid for each one, and what drives its effort up or down. Use it to write scope and quote requests, since no prices or durations are given here. The main takeaway is that course volume matters less than gradebook logic, quiz banks, integrations and testing.
| Cost driver | Who is paid and for what | What drives it and how to keep it down |
|---|---|---|
| Number of courses and media volume | Migration engineers for export, import and checking; the school or company for staff time reviewing courses | Count active courses, not archived ones. Remove obsolete media before export and agree a cut-off for which terms move. |
| Gradebook logic rebuild | Moodle developers or course-design specialists rebuilding grade items, categories and calculated grades | Common Cartridge does not carry all grade logic, so each calculated grade and weighting must be rebuilt by hand. Ask the vendor to list every grade rule before scoping. |
| Quiz and question bank conversion | Specialists who map question types and check scoring, plus instructors who verify sample quizzes | Question types that do not map directly need manual rework. Keep the question bank scope narrow and test a sample of each quiz type early. |
| Release conditions and adaptive content | Course designers who rebuild access rules in Moodle activity and restriction settings | Each release condition is rebuilt individually, so heavily gated courses cost more. Inventory conditions per course during discovery. |
| LTI re-registration | Integration engineers who register each tool in Moodle and reconfigure keys and launch URLs with each vendor | Every external tool needs its own setup and vendor cooperation. List all LTI tools and their owners before the cutover plan is written. |
| SIS and SSO integration | Identity and integration engineers, plus the school or company's identity and SIS administrators | Enrolment feeds, user identifiers and login flows must be rebuilt for the self-hosted site. Confirm identifiers and SAML or OIDC requirements with your identity team first. |
| Archive scope for learner records | Data engineers who export and store learner history, and records or compliance staff who approve the retention rules | Narrower archive scope with defined fields costs less. Agree retention periods and record formats in writing before export starts. |
| Plugin choices | Moodle plugin developers or the vendor of each plugin, and administrators who maintain them over time | Each added plugin adds install, upgrade and testing work. Prefer core features where they meet the need and check each plugin's maintenance status. |
| Testing effort | Test leads, course reviewers and instructors who sign off each course, and the DeployOpen or in-house team running the test plan | Scope of testing grows with the number of course types and integrations. Agree acceptance criteria and a sample size for each course type in the written scope. |
| Hosting and upgrade readiness | Infrastructure engineers for servers, database and web server setup, and the operator for ongoing upgrades | Moodle 5.1 requires the web server document root to point to the /public directory, and the PHP and database versions in each release set the upgrade path. Confirm the target version and platform before quoting. |
What usually goes wrong when moving courses off Brightspace
Most Brightspace-to-Moodle problems show up after the first import, when a course looks complete but a grade, release rule or login behaves differently. The cards below cover the failure points that recur in this move and the check to run before each one reaches learners.
Incomplete course package exports
A Common Cartridge or course package export may leave out components, so a course can import with missing quizzes, files or activities. Treat the export as a draft and compare the item count of each module against the Brightspace course before you accept it. Keep the source course read-only until the Moodle copy has been reviewed by an instructor. Ask Brightspace administrators which component types their export setting excludes.
Release conditions and calculated grades
Release conditions, prerequisites and calculated grade formulas often do not carry over as working logic, so content may open for everyone or grades may total incorrectly. Rebuild each condition and formula in Moodle by hand and record which ones were rebuilt. Test with at least one student account per condition path before the course opens. Assume these items need manual work until a test shows otherwise.
Grades that do not reconcile
Gradebook totals, weightings and dropped-score rules can differ between the two systems, so a migrated course may show a different final grade for the same learner. Export final grades from Brightspace, then compare a sample of learners line by line with the Moodle gradebook. Agree with academic or training owners on the rule for each grade category before cutover. Write down every difference you accept.
Learner history lost at cutover
Course packages do not carry completion history, submissions or attempt records, so learner progress can disappear when the course moves. Archive the Data Hub CSV exports for grades, enrollments and activity before the Brightspace contract ends, and store them in a location with a defined retention rule. Confirm which records your compliance or accreditation obligations require you to keep and for how long.
SSO attribute mismatches
When Moodle takes over sign-in, a different username, email or student ID attribute can create duplicate accounts or block existing learners from their courses. Map each attribute that identifies a learner in your identity provider to the Moodle profile field before any learner signs in. Moodle core includes several authentication methods, and the SAML2 plugin is a common choice where an identity provider is already in place, so confirm which one fits your setup.
Web root misconfigured on Moodle 5.1
From Moodle 5.1, the web server document root must point to the new /public directory instead of the main Moodle folder. If it does not, the site can show directory listings or errors at cutover. Check the web server configuration in a staging copy, and confirm the document root and PHP version against the release notes before you switch DNS. Confirm the database versions Moodle requires for the release you install.
Questions buyers ask before moving from Brightspace to Moodle
How much effort and cost should we expect when moving from Brightspace to Moodle?
The cost is driven mainly by the amount of course content, how much of it depends on Brightspace-specific features, and how many integrations must be rebuilt. Costs fall into one-time work (course export and import, rebuilding release conditions and calculated grades, quiz checks, SIS and SSO cutover, archiving learner records) and recurring costs (hosting, database and storage, Moodle upgrades, plugin maintenance and the administrators who run the site). Ask for a quote that separates these two groups and states which courses, integrations and data sets are in scope. No published Moodle hosting price or Brightspace module price is included in this page, so compare against your own current invoice line by line.
How long does a Brightspace to Moodle migration take?
The timeline depends on the number of courses, how many use advanced conditional release or calculated grades, how many LTI tools must be re-registered, and how quickly the SIS and SSO connections can be tested. A small pilot of representative courses usually shows the rework rate early, and that result is the best input for scheduling the rest. Plan a Moodle version before you start, because the target release sets PHP and database requirements. For example, Moodle 5.1 requires 64-bit PHP 8.2 or later and sites must already be on Moodle 4.2.3 or later to upgrade, while Moodle 5.3 requires 64-bit PHP 8.3 or later and an upgrade path from Moodle 4.4 or later. Ask any provider to state the duration of each phase in writing.
What does our team need to provide during the migration?
Your staff must supply decisions and access that only your institution can give. Typically this includes a list of courses to keep, archive or retire, owners who can confirm that a course has been checked, access to the Brightspace Data Hub or other export routes, and contacts for the student information system and identity provider. Your IT team also needs to decide where Moodle runs, who holds administrator rights, and how the web server document root is configured, since from Moodle 5.1 it must point to the /public directory. Faculty or trainers should review rebuilt quizzes and grading logic, because automated import does not prove that a question or grade still behaves as intended.
Can our own team do a Brightspace to Moodle migration without outside help?
A capable internal team can do it if it has Linux, PHP and database administration skills, time to test course by course, and someone who understands the grading and release logic in the current courses. Outside help is most useful for the parts that carry risk: the database and upgrade path, SSO and SIS integration, security hardening, backup and restore testing, and evidence for audits. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in your own infrastructure under a fixed scope agreed in writing before work starts, and it offers retainers for ongoing upgrades and support. Compare that option with a pilot your own team runs first, so you can judge the remaining work realistically.
How are learner records kept after we leave Brightspace?
Learner records do not move with the course package, so they need their own export and archive plan. Use the Brightspace Data Hub CSV exports for user-level data sets such as grades, enrollments and activity history, and store them in a controlled archive on your own infrastructure with access limited to the roles that need them. Decide the retention period with your records and legal teams before cutover. Keep the archive readable after Brightspace is switched off by documenting the file format and the field definitions. Some grade history may not be recreated in Moodle, so confirm which records must be preserved as they were.
What is included in a good quote for this migration?
A useful quote lists the scope in writing: the number and type of courses, the content formats to import (Common Cartridge packages and any other formats), the quizzes and question banks to check, release conditions and calculated grades to rebuild, LTI tools to re-register, and the SIS and SSO integration points. It should also name the deliverables, such as a tested Moodle instance, a cutover runbook, backup and restore evidence, documentation and training, and state what is excluded. Ask for the hosting and support assumptions, the upgrade plan after go-live, and who is responsible for learner record archiving. Request separate line items for one-time work and any recurring retainer so the totals can be compared fairly.
Which Brightspace features are hardest to move to Moodle?
The features that depend on Brightspace-specific logic usually need the most rebuilding. Release conditions, calculated grades, and some gradebook structures often do not carry over as working logic, so they should be recreated and tested in Moodle. Quizzes and question libraries may import with differences in formatting or scoring, and LTI tool connections must be set up again with new credentials. Check each course with a test student account before cutover and record the results, since this list is the main driver of rework.
How DeployOpen scopes and runs a Brightspace to Moodle migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, including the cloud accounts, data centers or air-gapped networks where the Moodle site will run. For a Brightspace to Moodle move, that means the engagement covers the target environment, the course content and the identity and student information system connections, not just a software install. Most engagements are fixed-scope, so the written scope should name the Brightspace course packages in scope, the Common Cartridge exports, the components that must be rebuilt by hand (release conditions, calculated grades, and any quizzes that need rechecking), the Data Hub archive of learner records, the SIS and SSO cutover steps, and the roles and acceptance tests that close each deliverable. Ask for that list to appear in the statement of work before any work starts.
A quote follows from the written scope. DeployOpen does not publish a price list, so the cost depends on the number of courses, how much content needs manual rebuilding, how many integrations must be re-established, how many environments (development, test and production) the client needs, and who on the client side will review and sign off each stage. Ask for the quote to separate one-time items (environment build, migration, testing, documentation and training) from recurring items. Ongoing support, Moodle upgrades and continuous testing are available as retainers, which matters because Moodle ships major releases in April and October and point releases every two months, and each upgrade path has its own PHP and database requirements. Confirm with the vendor which Moodle version the retainer will cover and how upgrades are scheduled around your academic calendar.
Before signing, confirm three things in writing: the scope and acceptance criteria for each deliverable, who holds the Moodle administrator and backup responsibilities after handover, and how learner records from Brightspace will be stored and protected once exported. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and independent auditors and certification bodies perform those assessments. If your institution or employer needs a formal assessment, plan that as a separate step with its own assessor.
