Why a SaaS company runs its customer academy on Open edX
Open edX fits a software or SaaS company that needs customers and partners to learn the product in an academy running in infrastructure the company controls, carrying its own branding and signing learners in through its own identity provider. If those three requirements are firm, the platform is worth evaluating in depth. If the academy only needs a few public courses on a separate domain, a hosted course service will usually be less work to start, and the decision should be made on those terms before any build begins.
Open edX is open-source software licensed under the GNU Affero General Public License version 3, written in Python and Django with JavaScript in the frontend. It delivers two core services: Studio, where course teams author content, and the LMS, where learners enroll, progress and earn certificates. The edx-platform maintainers recommend running it in production through a service provider or with Tutor, and they note that bare-metal installation is complex and receives limited community support. Make that recommendation the starting point for your architecture, and decide early whether your team or a partner will own upgrades.
Plan this as a product integration project. Course hosting is the smallest part of the work. The harder decisions sit at the edges: how learners sign in through your identity provider, which protocols connect to it (OAuth2 providers, SAML 2.0, Shibboleth or LTI, depending on what your provider supports), how branding and domain routing match your product, and how course content follows your product release cycle. Confirm your identity provider's exact protocol support and session behavior with its vendor before design starts, since sign-in problems are the most visible failures a learner can hit.
Check the infrastructure requirements before committing budget. Development requires Python 3.12, Node.js, MySQL 8.0, MongoDB 7.x and Memcached, and multi-node deployments need a shared Django cache backend such as Redis or Memcached. Confirm that your hosting environment, backup approach and staffing can support these services after launch. Also settle who operates the platform, who owns learner data and who answers for the academy when a course or sign-in path breaks. Those answers shape scope more than any feature list does.
What customer and partner academies require from the build
This table maps each requirement a customer or partner academy usually brings to the Open edX build, where that requirement comes from, and the decision it forces. Read it as a list of questions to settle before design starts, because several rows change which system owns the learner record. The main takeaway is that branding, commerce, identity and analytics share one learner identity, so the ownership decisions should be made once and written down.
| Requirement | Source or driver | What it means for the build |
|---|---|---|
| Branded sites and domains | Each customer or partner expects the academy to look like part of its own product and to run on its own domain | Decide how many sites exist, which domain each one uses and whether one LMS hosts several branded sites. Open edX multi-site support needs to be confirmed against the chosen release before the information architecture is fixed. |
| Course sales and checkout through a WordPress storefront | Marketing teams usually already run WordPress for product pages, pricing and checkout | Decide whether the storefront or the LMS owns the order and the enrollment. The integration must confirm payment, then enroll the learner, and it needs a defined path for refunds and failed enrollments. |
| SSO with the product's identity provider | Customers and partners expect staff and external learners to sign in with the identity provider they already use | Decide which identity provider is the source of truth for accounts, how partner users are provisioned and whether third-party authentication such as SAML 2.0 or OAuth2 covers every user group. Confirm the supported providers for the chosen release. |
| Learner activity analytics | Product and customer success teams ask how learners use courses and whether they complete certification paths | Decide where learner events are stored and who may query them. The Aspects analytics stack (xAPI statements, ClickHouse, Superset) is one option, and its data retention and access model must be designed before launch. |
| Partner-specific access | Partners often need to see only their own courses, cohorts or reports, and may need to manage their own learners | Decide how partner boundaries map to organizations, course visibility, roles and reporting scope. Test that a partner administrator cannot see another partner's learners or analytics. |
| Single-release support policy | Open edX states that the latest named release is the only supported release and that it cannot support more than one release at a time | Plan for periodic upgrades to the newest named release rather than a long-lived version. Budget for upgrade work as recurring effort and record which release every customizing plugin or XBlock is tested against. |
| Record ownership across systems | Identity, commerce, LMS and analytics each store part of the learner record | Name one system as the authoritative learner record and define how the others reference its identifier. Without this decision, duplicate accounts and conflicting enrollment states are likely. |
How branded sites and WordPress course sales fit together
The WordPress storefront should own everything a buyer sees before paying: marketing pages, the course catalog presentation, pricing and checkout. The Open edX LMS should own what happens after a purchase: enrollment, course delivery, progress and certificates. Write this split into the design document before the build starts. Most later disputes trace back to a fact, such as a price, a seat or a refund, that two systems both believe they control. For each piece of course information, ask the partner to name the source of record and the systems that only display a copy.
Domain layout is the first technical decision. One common pattern (illustrative) places the marketing site on the root domain and the LMS on a subdomain, which keeps sessions and branding separate and lets each side be upgraded on its own schedule. Decide early whether learners see the LMS under the brand domain or a separate host, because redirects after checkout depend on that choice. Theme ownership follows the same logic. WordPress templates control storefront pages, while LMS look and feel is maintained as Open edX theming in code your partner delivers and your team reviews. Two teams should not edit the same header or footer independently.
The purchase record is the most important design choice. Order data, payment references, tax details and invoices usually live in WordPress with the checkout system, while enrollment, learner access and certificates live in the LMS. The handoff between them is the integration point, and it needs confirmation. Check against the commerce integration documentation for the named release you choose whether it supports the flow you need: how a paid order creates an enrollment, how a refund removes access, and how failed handoffs are detected and retried. Do not assume that support from a plugin's marketing page or from a previous release.
Before committing, ask a partner to demonstrate a working purchase-to-enrollment path in a test environment. A useful demonstration places a test order with a non-production payment setup, shows the enrollment appearing in the LMS, runs a refund and confirms that access is removed, and checks that the purchase record reconciles with the enrollment record. Ask what they will change if the handoff fails, who maintains that code after launch and what work is needed when the Open edX release changes. Record the answers in the written scope so they are priced and tested, not left as assumptions.
Which Open edX modules and integrations matter for customer education
An academy for customers or partners depends on a few components that decide how it looks, who signs in, how courses reach your product and what learner data you can read. Each card names what to configure and what a wrong early choice costs to reverse.
Tutor as the deployment base
Tutor is the official Docker-based Open edX distribution. It has a plugin and hooks system and supports Kubernetes, and Edly maintains it and offers professional support. Configure the platform and Studio hostnames, the release version and the plugin list in one versioned project so the environment can be rebuilt. The costliest early mistake is choosing a release without a plan to follow it, because Open edX supports only the latest named release, so upgrades become unavoidable.
Studio course structure and libraries
Studio holds course outlines, units and the content libraries that partner courses reuse. Set course and library naming, ownership and instructor roles before the first course team starts. Check whether the chosen release needs Verawood's new Studio sidebar and taxonomy management, which were added in that release, and confirm this with the release notes. Adding a tagging vocabulary after many courses exist means reviewing each course's tags by hand, so decide the taxonomy first.
LMS theme and branding
The LMS theme controls logos, colors, header and footer links and the pages that make the academy read as part of your product. Keep the theme in its own version-controlled repository, with a staging environment for every change. Editing theme files directly on a running server is the costly mistake: upgrades overwrite the work and nobody can see what changed. Confirm which frontend plugin slots your product pages need before you build custom pages into the theme.
Third-party authentication
Open edX third-party authentication supports OAuth2 providers, SAML 2.0, Shibboleth and LTI, with older provisional support for CAS and SSL client certificates. Most software companies point it at the product's own identity provider so learners sign in once. Confirm which attribute serves as the unique identifier and how email changes are handled. Mapping the wrong identifier creates duplicate accounts, and those are hard to merge once certificates and enrollments exist.
LTI for embedding courses
LTI lets your product or a partner portal launch Open edX courses inside its own pages. Decide the direction first: your product as the tool consumer, or Open edX as the tool provider for a partner portal. Verawood added LTI Advantage Complete certification, so confirm with the release notes and the partner's platform whether it is required. Test launch parameters, roles and grade return against each partner environment before publishing any course.
Aspects for learner activity
Aspects captures tracking logs as xAPI statements through the event-routing-backends plugin. It stores them in ClickHouse via Ralph or Vector and presents them in Superset dashboards. Decide which events feed sales and customer success views before you enable it, and which learner fields are stored. Changing the event schema later breaks dashboards built on it. Learner activity is personal data, so agree the retention period and access model with your data protection team first.
How SSO with the product's identity provider is set up
Open edX third-party authentication supports OAuth2 providers out of the box. The docs list Google, Facebook, LinkedIn and Azure Active Directory by default. Use this path when your identity provider exposes OAuth2 or OpenID Connect endpoints and either appears in that list or can be configured as a compatible backend. Plan these items before the build starts:
- What the provider must supply: a registered application with a client ID and secret, a redirect URI that points to your LMS, and scopes that return a stable user identifier and an email address.
- Account matching: confirm whether the platform links an external login to an existing learner by email, by the provider's subject identifier, or by both, and how it behaves when a user changes email at the provider.
- Account creation: decide whether first sign-in creates a learner account automatically and which profile fields are populated from the provider.
- Role mapping: a successful sign-in does not by itself grant partner admin rights. Plan how administrators are assigned, for example manually in the LMS or through a provisioning step your team builds and tests.
- Older support: CAS and SSL client certificate options have only older provisional support in the docs. Treat them as a risk to review before you choose either.
Confirm the client registration fields, scopes and claim names with your provider's own documentation before you design the account model.
SAML 2.0 and Shibboleth are common where the customer or partner already runs a federated identity service. The work centers on metadata exchange, attribute release and certificate handling, and most sign-in failures trace back to one of these. Plan these items with the identity provider's team:
- What the provider must supply: service provider metadata exchange, the entity ID, the signing certificate, and an attribute set that includes a persistent user identifier and an email address.
- Account matching: match on the persistent identifier the provider releases. Do not match on display names. Confirm which attribute the platform uses and whether email is trusted for linking existing accounts.
- Account creation: first sign-in can create the account from released attributes. Confirm which attributes are required and what happens to a user when one is missing.
- Role mapping: attributes such as group or affiliation can drive roles only through a mapping you define and test. The platform does not assign meaning to attribute names on its own, so write the mapping table before go-live.
- Certificate lifecycle: agree on signing certificate rotation and metadata refresh with the provider. An expired certificate blocks sign-in for every user at once.
Confirm the entity ID, attribute names, binding types and certificate lifetime with the identity provider's SAML documentation before you request the metadata exchange.
LTI launches let a host platform start an Open edX session for a learner, typically from a campus or partner system. The host signs each launch request, and Open edX verifies it before it starts a session. The Verawood release notes list LTI Advantage Complete certification, but the features your host needs still have to be confirmed against the release you deploy. Plan these items with the host's administrators:
- What the host must supply: a tool registration with a client identifier, the platform's public key set or shared secret, the launch URL, and a deployment identifier.
- Account matching: identify the learner from the launch's user identifier together with the issuer, so the same identifier from two hosts stays separate.
- Account creation: confirm whether a first launch creates an account and which claims populate the profile.
- Role mapping: the launch carries role claims from the host, such as instructor or learner. Map each host role to a specific course role in writing. A launch should never grant partner admin rights.
- Session scope: confirm how long a launched session lasts and how a learner signs in directly when the host session has ended.
Confirm the registration fields, supported LTI versions and role vocabulary with the host platform's documentation before you map roles.
Measuring learner activity with Aspects
Aspects is the analytics layer for Open edX, and for a SaaS team the first decision is which learner activity should feed product analytics at all. The event-routing-backends plugin captures tracking logs from the LMS and forwards them as xAPI statements. Those statements are stored in a ClickHouse database through Ralph or Vector, and Superset dashboards present them. Before installation, list the events you need, such as course enrollment, video playback, problem attempts, certificate issuance and course completion, and separate them from events you do not need. Every event you forward is a record your organization must store, secure, retain and eventually delete, so a shorter list keeps the scope of the data protection review smaller.
Learner identifiers and pseudonymization need a deliberate design. Aspects statements refer to learners through identifiers, and your team must decide whether those identifiers are pseudonymized before they reach ClickHouse, how the mapping back to a named account is kept, and who holds that mapping. The reversible key should sit in a separate system with its own access controls, not in the analytics database. Confirm with your data protection team whether pseudonymized data is still personal data under your privacy obligations, whether a data processing agreement covers the analytics vendor or hosting provider, and how learner requests for access or deletion will reach the analytics store. Record each decision so the answer is available to auditors.
Retention periods are set per data category, not once for the whole stack. Raw xAPI statements, aggregated dashboard tables and the identifier mapping usually have different legitimate purposes and should have different retention rules. Decide how long raw events stay queryable, when they are aggregated or deleted, and how backups of ClickHouse age out. Retention in the analytics database alone does not cover copies in backups, logs or exports, so include those locations in the plan.
Partner-level reporting adds an access question. A partner academy may want to see enrollment and completion for its own courses or learners, but should not see another partner's learners or your internal product usage. Superset dashboards need row-level or dataset-level restrictions keyed to the partner, and you should test those restrictions with a non-admin account before any partner is given access. Confirm with your team which Superset roles, datasets and filters implement this, and do not rely on dashboard visibility alone.
The analytics stack is a separate system from the LMS. ClickHouse storage grows with event volume, Superset needs its own database and access model, and Ralph or Vector need monitoring and restore procedures. Size these components, plan their backups and test a restore before go-live. Ask your data protection team for storage location, transfer, access and retention requirements, and get written answers before scoping, because those answers determine hosting, pseudonymization design and the effort of the build.
Compliance duties for customer and partner learner data
When your company or a partner hosts learner data for customers, the academy becomes a service with obligations to those customers. DeployOpen prepares the controls, configuration and evidence for each duty, while independent auditors issue SOC 2 reports and accredited certification bodies issue ISO/IEC 27001 certificates.
GDPR Article 28(3) processor terms
When your company or a partner hosts learner data for a customer, the host acts as a processor and needs a written contract under GDPR Article 28(3). The contract must bind the processor to act only on documented instructions from the customer, including instructions on transfers, and to apply the security measures Article 32 requires. For an Open edX academy, confirm who is controller for enrollment, progress and certificate data, which sub-processors run the hosting stack, and where backups and analytics copies are stored. Ask counsel to confirm the transfer mechanism before any learner record leaves the agreed region.
GDPR Article 32 security measures
Article 32 requires measures appropriate to the risk, including encryption and pseudonymization where suitable, the ability to keep systems confidential and resilient, the ability to restore access after an incident, and a process for testing effectiveness. For Open edX, turn these into named controls: TLS on the LMS and Studio, encrypted database and object storage, restricted administrator access to the Tutor-managed cluster, tested restores of the MySQL and MongoDB data stores, and logged access to learner records. Record each measure with an owner and the test that shows it works.
SOC 2 under the 2017 criteria
SOC 2 examinations report against the AICPA 2017 Trust Services Criteria in five categories: security, availability, processing integrity, confidentiality and privacy. The security common criteria, CC1 to CC9, apply to every SOC 2 report, so a learner data platform is assessed on its governance, risk, access, operations and change controls. A Type 1 report describes the system and the design of controls at a point in time. A Type 2 report adds an opinion on operating effectiveness over a period. A general-use SOC 3 report is designed for broad distribution. Confirm with the auditor which categories and report type your customers expect.
ISO/IEC 27001:2022 Annex A themes
ISO/IEC 27001:2022 Annex A lists 93 controls in four themes: organizational (37), people (8), physical (14) and technological (34). For a self-hosted academy, the technological theme carries most of the platform work, covering identity, access, logging, backup, secure configuration and secure development of custom XBlocks and theme code. Physical and people controls often fall to the hosting provider or your own staff. Only accredited certification bodies certify an organization, on a three-year cycle with at least one audit in each calendar year. Ask the certification body to confirm the scope it will accept before the build starts.
EU Data Act switching rules
The EU Data Act, Regulation (EU) 2023/2854, has applied since 12 September 2025. If the academy is offered to customers as a data processing service, the provider must let a customer switch to another provider or to on-premises ICT infrastructure. The rules set a maximum two-month notice period and a 30-day transitional period (Articles 23, 25 and 50). From 12 January 2027, providers may not impose switching charges, and until then reduced charges may not exceed costs directly linked to switching (Article 29). Plan exports of course content, learner records and credentials before a customer asks to leave.
How a customer academy rollout runs
The rollout moves from a signed fixed scope to a live academy in a set order. Each phase produces a decision or test record that a named client owner signs off before the next phase starts, so identity, storefront, analytics and security are proven in a test environment before any partner learner uses the site.
Agree the scope and sign the fixed-scope agreement
The team documents the academy's purpose, audiences, course catalog boundaries, identity provider, storefront, analytics needs and exclusions, then turns them into a written scope with deliverables. The Open edX release is named here, because the latest named release is the only supported one, and the current named release is Verawood. The business owner and procurement sign the agreement. Output: a signed scope document that lists the release, integrations and acceptance criteria for each later phase.
Stand up a Tutor environment on the chosen release
Engineers deploy Tutor, the official Docker-based Open edX distribution, into the client's cloud account, data center or private network, pinned to the release from scoping. The maintainers recommend running Open edX through a service provider or with Tutor, since bare-metal installation is complex. Tutor also supports Kubernetes deployments. Output: a running LMS and Studio in a non-production environment with the version and configuration recorded. The platform engineering lead signs off.
Integrate identity and SSO in a test tenant
Engineers connect the product's identity provider using a protocol the provider supports, such as OAuth2, SAML 2.0 or LTI. Older options such as CAS and SSL client certificates have provisional support, so the team confirms them against current documentation before choosing one. Test cases cover sign-in, logout, attribute mapping and role mapping for learners, partners and course staff. Output: a passing test matrix and an agreed attribute map. The identity owner and the security lead sign off.
Build the branded site and test the storefront
Designers and engineers build the Open edX theme with the client's brand, then connect the WordPress storefront that sells courses. The purchase path is tested end to end: catalog listing, checkout, payment confirmation, automatic enrollment, receipts and refunds. The team confirms the connection method for the chosen release and plugins before building. Output: a test purchase log in which every paid order maps to one enrollment. The marketing owner and the finance owner sign off.
Validate the analytics pipeline on test activity
The Aspects analytics path captures tracking logs through the event-routing-backends plugin as xAPI statements, stores them in ClickHouse through Ralph or Vector, and presents them in Superset dashboards. Engineers run scripted learner sessions and compare the recorded statements and dashboard figures with the expected results. The team also confirms which learner fields leave the platform. Output: a reconciliation report and a list of approved metrics. The data owner signs off.
Complete the security and access review
The team reviews administrator roles in Studio and the LMS, secrets storage, network exposure, backup and restore settings, logging and the processor terms that cover any personal data handled during operation. Auditors and certification bodies handle assessments, so DeployOpen prepares the systems, controls and evidence for them but issues no attestation. Output: an access review record and a findings register with owners and resolution dates. The client's security lead signs off before any partner uses the platform.
Run a pilot with a small partner group
A small partner group enrolls in live courses on the production-grade environment, and the client's support team handles their questions through the agreed process. Defects, confusing steps and content issues are logged, triaged and fixed against the exit criteria set during scoping. Output: a pilot report listing resolved defects, open risks and a go or no-go recommendation. The partner program owner signs off on the exit criteria.
Cut over with runbooks and a tested restore
The team moves the academy to its public address, migrates any pilot accounts and records that the production backup has been restored successfully in a separate environment. Runbooks cover deployment, upgrades, backup and restore, storefront issues and incident response, and the client's operations team takes them over. A rollback plan is agreed before the switch. Output: a signed cutover checklist and a handover package. The operations owner and the business owner sign off. Ongoing support, upgrades and testing can continue under a retainer.
Which Open edX release to build on and how to plan upgrades
The first decision for a customer or partner academy is which named Open edX release to build on, and the answer shapes everything after it. Open edX states that the latest named release is the only supported release and that it cannot support more than one release at a time. Verawood, the current named release, was published on 30 July 2026. The next releases, Willow and Xylon, are listed for December 2026 and June 2027. Before the build starts, confirm this calendar on the official Open edX release notes page, because the dates and support windows are the facts that determine when your academy must move.
Building on the current release gives you the most recent features and the longest remaining support window before the next upgrade. Verawood added a new Studio sidebar, a redesigned instructor dashboard, an AI Extensions Framework, tagging and taxonomy management, new frontend plugin slots and LTI Advantage Complete certification. For a sales-led academy, the new frontend plugin slots and the LTI support may matter if you plan branded pages or external tool launches. Planning for the next release instead means accepting a release that is not yet published, which adds risk to the build. Most teams should build on the current release unless a feature they need only exists in a later one, and should write down the reason if they choose otherwise.
Custom XBlocks, your theme and any plugins are where upgrade effort concentrates. Each custom XBlock, theme override and Tutor plugin depends on platform interfaces that may change between releases. Keep a register that lists each component, the release it was tested against, its owner and the upstream interfaces it touches. Prefer frontend plugin slots over direct overrides where the release provides them, and keep theme changes small. Ask your implementation partner to show how the test suite runs against a new release candidate, since a passing build alone does not prove that course sales, SSO and learner tracking still work.
A long-lived customer academy needs an upgrade plan that runs for years, not one that ends at launch. Set a recurring review point for each named release, assign who approves a move, and reserve a staging environment that mirrors production data shape and identity configuration. Plan around the course sales flow through WordPress, the SSO connection to your product's identity provider and the Aspects analytics pipeline, because each has its own dependency on the platform version. Ask the partner to quote the upgrade work as a separate, repeatable scope, and confirm in writing how the platform and its plugins are tested before each move.
What buyers ask before they hire a partner for a customer academy
What drives the cost of building an Open edX customer academy?
The main cost drivers are the number of sites and brands, the volume of course design and content migration, the number of integrations to build, and how much custom frontend or XBlock work the brand requires. Each adds design, build and test effort. The state of your source material matters as much as platform setup, because courses that need rewriting cost more than courses that can be migrated as they are. Hosting size depends on learner volume and how long analytics data is kept. Ask for a written quote that separates discovery and architecture, configuration, identity and commerce integration, content migration, testing, handover and ongoing support, and marks which items are optional so you can phase the work.
Which Open edX costs are one-time and which recur?
One-time costs cover discovery, information architecture, course design, branding, integration builds, content migration, acceptance testing and the initial hosting setup. Recurring costs include the hosting and infrastructure that run the academy, platform upgrades, support and monitoring, and storage for analytics data, which grows with learner activity. Upgrades are a recurring commitment because Open edX supports only its latest named release at a time, and Verawood is the current named release, published on 30 July 2026. Course production and content updates also recur. Ask the quote to label each line as one-time or recurring, and to state what is included in the first year of support.
Can an in-house team run an Open edX academy without a partner?
An in-house team can deliver an academy, but only if it covers the full stack. The skills include Python and Django for the LMS and Studio, React for micro-frontends, Docker and Kubernetes for Tutor deployments, MySQL, MongoDB and Memcached, identity federation over OAuth2, SAML 2.0 or LTI, analytics pipelines, and instructional design for course structure. The edx-platform maintainers recommend running Open edX in production through a service provider or with Tutor, because bare-metal installation is complex and has limited community support. Before deciding, list who will apply each upgrade, who holds on-call duty, and who maintains custom code after the first launch.
How long does an Open edX customer academy take to build?
The timeline is set by the agreed scope and by client dependencies, more than by installing the platform. The main drivers are the number of brands and sites, how many courses must be designed versus migrated, how quickly your identity provider access is granted, the commerce and analytics integrations, approval cycles for branding and content, and the number of test rounds. Work usually stalls on dependencies such as late content, unresolved identity questions or slow sign-off, so those should be named in the plan. Most DeployOpen engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. Ask for a schedule tied to milestones and to the client decisions each milestone depends on.
What does the client need to provide for an Open edX academy?
You need to provide access and decisions that the build cannot proceed without. These include access to your cloud account, data center or hosting environment, a technical contact at your identity provider with the protocol details (OAuth2, SAML 2.0 or LTI, depending on your stack), brand assets such as logos, color rules and font licenses, sample courses or source files for design and migration, and a catalog structure and pricing model. You also need test accounts and a named business owner with authority to approve content, scope changes and launch. Confirm early who that owner is, because approvals that wait for a committee tend to extend the timeline.
How is WordPress checkout connected to Open edX, and is custom code needed?
The connection method depends on how your WordPress store sells course access and passes each purchase to the LMS, so confirm it during scoping before any build estimate is made. Key questions include whether an existing integration or maintained plugin covers your order flow, how enrollment is triggered after payment, how refunds and failed payments reach the LMS, and where customer records are held. Custom code becomes likely when pricing rules, bundles or enrollment logic go beyond standard options. Ask the partner to name the integration path, list every custom component, and state who maintains those components through platform upgrades and WordPress updates.
What compliance evidence can a partner provide for an Open edX academy?
A partner can prepare the systems, configuration baselines, access controls, backup and change records and other documentation that an auditor or certification body will examine. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors issue SOC 2 reports, and accredited certification bodies certify ISO/IEC 27001. A SOC 2 Type 1 report describes control design as of a date, while a Type 2 report adds operating effectiveness over a period, so evidence must be collected continuously. Ask which controls are in scope, who gathers evidence after handover, and which data processing terms your legal team needs for the hosting and processing arrangements.
How DeployOpen scopes, builds and supports a customer academy
DeployOpen plans, builds, documents and supports Open edX as a customer or partner academy inside infrastructure you control. Each engagement starts from a written scope covering the branded sites, course sales, identity integration and learner analytics you need, and the work is delivered in that agreed shape.
How we scope
- Engagements are fixed-scope, with the academy's sites, courses, sales flow and integrations agreed in writing before work starts.
- The scope names the identity provider, such as your product's SAML or OAuth2 provider, and confirms which login paths learners will use.
- Analytics needs are defined up front, including which learner activity is tracked and which Superset dashboards your team will read.
How we build
- Tutor is the base for deployment, with plugins and hooks used for branding, course sales through WordPress and identity settings.
- Custom XBlocks or frontend changes are built only where the agreed scope needs them, and each change is tested before release.
- Learner analytics are set up through the event-routing and Aspects tooling, with dashboards checked against the agreed reporting questions.
How we hand over
- Handover includes the deployment configuration, plugin code, identity settings and runbooks your team needs to operate the academy.
- Test records show how sign-in, course purchase and enrollment were verified against the written acceptance criteria.
- Documentation covers backups, restores and the steps to add courses, sites and identity providers without vendor involvement.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing like the original build.
- Upgrades follow the named release in use, since Open edX supports only the latest named release at any time.
- Ask any partner to confirm response times, upgrade windows and who holds production access before signing a support agreement.
