ECDN Technical Brief

BUSINESS PROBLEM #

The problems that arise from running live video events impacts many areas of the organization:

The Corporate Communications Challenge:

• Challenging deadlines for live events
• Difficulty in achieving global reach – every office and employee
• Challenge meeting employee quality expectations
• Availability of real-time and historical analytics showing event success
• Visibility around content resonance

The Technical Challenge:

• Challenging deadlines for live events
• End-to-End network impact of high bandwidth, high definition Live Events with many concurrent users
• The ability to measure the specific network impact of live events
• The constraints of security and compliance in achieving goals

SOLUTION OVERVIEW #

An increasing number of video platforms enable simple communication that scale to many thousands of users for live or on-demand content but create a technical challenge to deliver concurrent usage at scale. The ECDN is designed around 3 core principles, Easy to Deploy, Easy to Maintain, Easy to Scale and solves the network challenge allowing you to achieve 100% global user reach at a fraction of the bandwidth:

• No requirement to add hardware or increase bandwidth, utilize innovative peering technology to reduce the bandwidth required to deliver a high-quality video viewing experience for every user.
• No requirement to install software agents or modify network and security infrastructure.
• Simple adoption with self-service integration of the ECDN with Microsoft or other solutions including WTV, Notified, Brightcove, Kaltura, On24, Panopto, Touchcast etc. The Customer Portal provides all the required configuration elements and analytics and is integrated with existing Single-Sign-On.
• Advanced controls to optimize ECDN operation using private/public IP address/subnet, URL connectivity, machine name regular expression and bitrate filters without the requirement to install an agent.
• All network topologies are supported, including wireless, VPN, and MPLS and there is no significant incremental load on machine resources beyond what is required to render video.
• Advanced features to meet specific use cases that enhance end-to-end network efficiencies.
• Self-service test facility that enables interactive functional testing or silent Network Readiness Testing across 1000’s of users to prove event success at scale.
• Near real-time analytics provide feedback about content consumption and user-experience with visibility into associated network usage.
• Self-service controls for security and compliance policies to meet enterprise requirements for personal data.
• Support for IPv4 and IPv6.

The following diagram provides a summary of the ECDN solution stack:

The platform consists of the following components:

INTEGRATION PARTNERS #

A selection of the partners that the ECDN solution integrates with. Where a customer has their own 3rd party AV provider or webcasting platform the Integrator Portal provides simple instructions for integrating against supported players.

CONTROL LAYER #

Critical to the ECDN platform is separation of the Control from delivery layer. This design means that functions such as management, control and analysis are separate to the delivery architecture and therefore components such as location configuration are not reliant on implementation of a software agent.

INTELLIGENCE & DELIVERY #

Separation of the Control and Delivery layers allows implementation of the ECDN at the Edge to be determined by use case rather than technical capability. For example, rapid deployment using agentless Browser Based Peering can be undertaken in minutes for Live Events without loss of bandwidth saving or control functionality such as delivery, bitrate, etc. or without reduced analytics.

Intelligence and Delivery is split into three sub-components:

Browser Based Peering (BBP) and Agent Based Peering (ABP)

The following diagram demonstrates the efficiency of the ECDN using live video as an example. Without the ECDN, many users connecting simultaneously to live events saturate enterprise networks resulting in a poor user experience for the event while impacting other network services. The ECDN reduces bandwidth utilization by distributing the content within the network while maintaining strict controls over peering boundaries using an agentless (BBP), agented (ABP) or hybrid solution:

The use case will typically determine the requirement for which deployment option is selected. The following table providing a summary of the primary differences between the solutions with clarification of Use Cases throughout this document

*Road-mapped Feature

Where video is the primary use case it is typical that an agent isn’t deployed. The following points summarize the agent enhancements:

• Video on Demand

  • Browser Based Peering benefits concurrent viewership of VoD, common after a townhall or where a VoD link has been distributed for synchronized viewing and is in effect treated in the same way as a live event. The agent enhances content availability by peers through the creation of a distributed cache, writing the content to disk for ECDN-sourced retrieval at any time.

• Distribución de software

  • Our solution extends beyond video into Software Delivery integrated with Microsoft Endpoint Manager through Microsoft System Center Configuration Manager (SCCM) and Microsoft Intune.

• Automated Network Discovery

  • The agent can perform functions that are not permitted by browser controls, such as discovery of the network topology, and use this for enhanced ECDN management and control.

• Additional Browser Support

  • Legacy browsers including Internet Explorer provide analytics about events but do not currently include the technology to take advantage of Browser Based Peering. Where legacy browsers are still a requirement, we recommend the use of an Agent.

• Peer-to-Peer communication

  • Browsers can be configured to restrict the number of ports required for WebRTC ECDN usage however at this time the Microsoft Teams client cannot be configured in the same way. Where there are strict requirements on connectivity between peers an agent reduces that communication to a single port.

EdgeCache

EdgeCache is a customer-hosted server that serves as a “proxy” or aggregation point for streaming traffic and helps to extend network efficiency end-to-end by reducing bandwidth utilization, limiting the number of concurrent connections, and reducing latency from desktops.

EdgeCache helps overcomes limitations within corporate requirements including:

• Customer Web Proxy servers unable to handle streaming load. A bypass of proxy is challenging due to number of service providers CDN endpoints and changes.
• Reducing Internet egress utilization with backhauled networks and a high number of remote offices.
• Serving users within China if streaming service provider does not utilize local CDN PoPs.
• Aggregation within the network such as to tunneled VPN or Wireless users where peering is not beneficial.
• Managing split tunneled security requirements for changing CDN addressing in a timely manner can be challenging for security teams.
• Where latency between user and origin is very high

The following diagram provides a summary of Edge deployment in conjunction with remote offices:

BBP/ABP vs EdgeCache

For a detailed overview of EdgeCache including deployment requirements please see associated documentation however the following can be used as a summary use case scenario:

USER EXPERIENCE #

The ECDN is designed to be transparent to users and critically the start time for video playback, known as time-to-first frame, is typically 1-3 seconds, comparable to a native connection that does not use an ECDN.

ON-BOARDING #

There is a self-service portal provided at https://portal.kollective.app.

that includes all the required configuration and instructions to enable the solution within your video platform. By applying the configuration into the Office 365 administration console, or providing configuration tokens to the 3rd party, this enables the ECDN functionality and once enabled, no further action is required in the front-end.

The following screenshots provide an example of the simple configuration requirements which are typically completed in just a few minutes:

• Go to https://portal.kollective.app., select “Start Free Trial”. Enter company details and login using your Microsoft Office 365 or G-Suite Account Credentials. A tenant will automatically be provisioned.
• Select the products for configuration with relevant Quick Start videos for setup assistance, if using Microsoft Teams or Stream, apply the tokens through the O365 administration console, if using another solution either supply the tokens or configure within the relevant platform:

• Additional steps include the “Network Configuration Wizard” to help tune configuration, “Am I Ready?” test to prove connectivity and a “Rapid Network Test” that can assist with functional testing with users:

NETWORK READINESS TEST #

The NRT utilizes the browser-based delivery model and therefore does not require an agent to run. It is provided through self-service configuration within the customer portal at https://portal.kollective.app.

Our organization can support your IT team to create a test that replicates the audience size, time, and geography of your upcoming meeting or deployment design goals and test different bitrates to determine the optimal video codecs for your users. This is the baseline for network performance, and will indicate which video bitrates are successful, and where congestion issues may arise in your network.

Where the test runs in an agentless environment there is no agent to automate the NRT and therefore the scheduling of the NRT will utilize tools that are typically available in the enterprise environment to start the event across the required audience. Documentation can be provided to assist this deployment with Microsoft Endpoint Manager.

During the test a combination of ECDN analytics and customer network management utilities are typically used to analyze distribution where ECDN analytics detail the NRT, bandwidth savings, user experience, etc. as a way to recognize where remediation may be required. Customer tools provide local link utilization.

Please see the separate NRT Technote for detailed information on configuration and deployment of the NRT.

INTELLIGENCE AND INSIGHTS WITHOUT COMPRISING PERSONAL DATA #

The ECDN analytics provide near real-time business intelligence and insights for live and on-demand content using pre-configured and customizable dashboards. These provide the key stakeholder metrics for live events including Reach, Quality of Experience, Bandwidth Savings, View Duration, Bitrate selection, etc. to provide a rounded view of your communications events. Any metric in the platform can be configured for alerting to notify administrators of threshold breach.

The ECDN analytics provide trend and detailed analysis functionality to help you analyze your events relevant to business and technical stakeholder needs and all content is available for export in multiple formats, including webhook, to enable further analysis within your own BI platform:

The key metrics which are available by Event/Content, Location and individual user, are:

• Quality of Experience Score – quickly identify event success
• Reach – the individual number of users who joined the event
• Duration – how long was each user engaged
• Bandwidth Savings – the content delivery savings delivered by the ECDN
• Peering Efficiency – against pre-defined metrics the effective efficiency of the delivery
• GeoView – Graphical mapping to demonstrate distribution of audience
• Country View – Based on public IP address registration
• User Metrics including session ID, Quality of Experience, browser agent, buffering timers, startup time, start/end time, private IP address, public IP address (with associated longitude/latitude lookup), delivery information by source, etc.

Managing Personal Data

Managing personal data is of primary concern to enterprises where the definition of personal data can also differ between organizations. This solution has configurations to protect personal data in the following ways:

• Customer Portal Users
  • The customer portal utilizes Auth0 to provide single-sign-on authentication of users to the customer portal . The portal is used for administration and analytics of the platform, typically by only a small number of users within a customer organization. Where there is a concern over private information then anonymized accounts, (for example customer.admin1, customer.admin2), can be created by the customer within their own Active Directory for each user that requires access to the portal.
• ECDN Users
  • Storage of the O365 Object ID (provided as a GUID) s optional, disabled by default and only provided as part of an opt in policy managed by self-service configuration within privacy settings at https://portal.kollective.app/account-settings#tab2. This does not contain personal data that can be used by the portal or the ECDN, the GUID can be used by a customer administrator with appropriate permissions to match the O365 ID stored in Active Directory for Microsoft events.
  • Storage of email addresses (supported integrations including Microsoft Stream, Teams and Kollective Webcaster) is optional, disabled by default and only provided as part of an opt in policy managed by self-service configuration within privacy settings at https://portal.kollective.app/account-settings#tab2.
  • Storage of the Machine Name and Logged in user (agent only) is optional, disabled by default and only provided as part of an opt in policy managed by self-service configuration within privacy settings at https://portal.kollective.app/account-settings#tab2.

  • IP addresses are a critical requirement for our peering technology, but this data will only be kept transiently during the event and purged on event completion where required. Storage of Private and Public IP addresses is a configurable option and is enabled by default.

• Event and VoD Titles:

  • Where a customer considers Event or VoD titles are personal data then these can be obfuscated by support through opt-out. By default the event title is stored and visible in analytics , if enabled this option will utilize an event ID rather than event title.

TECHNOLOGY ARCHITECTURE #

The ECDN operates a cloud-native architecture built on the following standards:

• Global, low-latency architecture
• Designed around Microsoft Azure to provide elasticity, scalability, redundancy, regional resilience and data compliance.
• Located in Azure West Europe and Azure West US Azure zones in an active-active configuration with availability zone failover and regional failover configured.
• CloudFlare for global load balancing to ensure that the ECDN cloud services are accessed at the closest point of presence.
• Advanced telemetry, monitoring and proactive alerting from all systems.
• Zero downtime patching.

OPERATION #

The following diagram summarizes operation of the ECDN for BBP or ABP from event production, through registration, content retrieval and analytics with each step described below:

Production and End User ApplicationIn (Step 1) the producer sets up the Microsoft Teams event, the tenant will already be configured for the ECDN integration with a SDN Provider API Service Token and SDN Provider API Template URL . End users will connect to the event in the standard way, there is no additional steps or configurations that have to be applied. (Step 2).

PublishingAs events are created (and updated), Microsoft automatically ‘publishes’ the event with the ECDN platform (step 3). The connection is secured via HTTPS (TLS) protocol, where Microsoft verify the identity of the ECDN server using its public certificate.

The published object includes the Tenant ID and Service Token for authentication purposes and the content title and list of source URLs. In response, the ECDN will provide Microsoft with a Content Token JWT that is unique to the event. This Content Token is stored by Microsoft for later circulation to end users who are permitted to join the event.

Note that the ECDN does not ingest the content from the source URLs. The sources are provided simply to enable the peering of segments contained within that source playlist.

Publishing uses the ECDN’s content API server https://content.kollective.app.

SDK and PlaybackThe SDK is a JavaScript resource and is approximately 800Kb in size, retrieved from https://cdn.kollective.app (Step 4). The SDK provides the integration for the ECDN solution, enabling peer to peer optimization and reporting analytics. All integrations use the same core SDK code, varying only by release version. As the SDK is run in the browser context it has the same restricted sandbox access as any web application.

The JavaScript SDK does not depend on installed Extensions (formally called plugins) or external applications and does not require any elevated user privileges or user interaction for operation. Note that an installed agent can also be provided as an alternate option.

Microsoft will include the JavaScript SDK in the attendee web pages; the page loads much as it would without the Javascript SDK, first verifying the users permission to view. When permitted, it retrieves the Content Token specific to the event and instantiates the SDK, passing it the Content Token.

The SDK verifies the Content Token with the ECDN (Step5) and retrieves the location specific configuration.

Registration and Signaling (Step 6)

Depending upon configuration, the SDK will communicate with the cloud to determine which peering cluster the node belongs to, and at which tier the node sits within a peer cluster. As peers join the cluster, they automatically order themselves into an optimum configuration for content delivery.

The node registers itself via https to https://signal.kollective.app. This is followed by a websocket connection to signal.kollective.app, over which signaling is maintained throughout the session to orchestrate the ECDN mesh.

Sourcing Content – Without EdgeCacheThe first user in the mesh will source content directly from the Azure CDN using HTTPS with the metadata URLs received during publishing (Step 7) . As such, for a single user, there is no difference in user experience to using the ECDN vs without.

The ECDN’s algorithms download the individual fragments that make up the video stream across multiple nodes in a rotational manner. The net result is still a single stream, however with additional resilience and ability to monitor performance of individuals.

Sourcing Content – With EdgeCache (not shown)

Where EdgeCache is deployed, ECDN Location configuration determines EdgeCache to source the content from the partner CDN and then becomes the content source for users in either BBP, ABP or Blackout users (peering disabled).

Please see associated EdgeCache documentation for more details.

Peering

Additional nodes will source the content from their peers within the ECDN’s mesh.

• Interconexión basada en navegador
  • Each peering node retrieves information about other nodes via the signaling process. The requesting node will establish a WebRTC communication session with other nodes to determine and request the required data from available peers using the WebRTC data channel as the transport mechanism (Step 8).
  • Peer to peer communication utilizes DTLS/SCTP over UDP as the reliable and secure transport between nodes. DTLS provides secure encrypted channel, SCTP provides a reliable connection with congestion control.
• Agent Based Peering
  • Each peering node retrieves information about other nodes via the signaling process. The requesting node will establish a WebRTC communication session with other nodes to determine and request the required data from available peers using the WebRTC data channel as the transport mechanism
  • Peer to peer communication is secured utilizing TCP+SSL using Agent self-signed certificates for encryption.

Peers can join or leave the mesh without impact to other users, if a peer leaves the mesh others will simply adapt and reposition themselves without impact to the user viewing experience.

Each receiving peer will monitor the performance of peer node they are sourcing from and in the event of poor supply or other indicators, will request the content from alternate peers. If a user is unable to communicate with other peers, the machine will fall back to the CDN for content retrieval.

In an environment where workstations are restricted from direct communication with other desktops (East-West) e.g. crossing VLANs via a firewall/router an exception will be required to allow connectivity.

At all times peering is governed by strict rules that control how the ECDN will operate based on individual or a combination of elements including:

• Unrestricted: Any node can peer with any other node.
• Public IP address: Create mesh cluster based on matching the same or a configurable list of external IP addresses.
• Strict subnet definition: Create mesh cluster based on matching a configurable list of private IP subnets.
• Subnet size: Create mesh cluster based on subnet mask size. This is particularly useful where there are a large number of branch offices with similar configurations.
• URL reachability: Create mesh cluster based on ability to reach configured URL, typically used as a way to identify remote or office users.
• Machine name: Create mesh cluster based on regular expression machine name configuration.
• Event bitrate: Used to restrict available bitrates. In an event where multiple bitrates are published, e.g. Microsoft Teams, this can be used to restrict required sites to only a subset of the available rates, typically used in office locations where bandwidth availability is extremely challenged.
• Blackout: Used to disable peering, for example in combination with definition of VPN subnets.

Telemetry (Step 9)The plugin sends viewership data using HTTPS to https://stats.kollective.app/ in near real-time for analytics purposes with user and network performance metrics available to view via the Customer portal described above to.

Additional Note Regarding IP Address Anonymization and mDNS – Relevant to Browser Based Peering

Additional Note Regarding IP Address Anonymization and mDNS – Relevant to Browser Based Peering

IP Address Anonymization is a feature of modern browsers that support WebRtc to conceal the internal IP address of the desktop from any site on the web that may be deliberately invoking WebRtc to obtain IP address information and compromise the privacy of the user. It does so by revealing only a temporary allocated hostname, resolvable by the browser using mDNS (Multicast DNS).

The ECDN supports mDNS for anonymization of IP addresses and support can provide separate technical documentationd with a detailed description of the technology together with best practices for configuration.

SECURITY AND COMPLIANCE #

The ECDN solution is Secure by Design, architected using standard web-based protocols with all data transfers encrypted and signed.

• All communication to the cloud is HTTPS using TLS 1.2 with authenticated tokens used as the security layer.
• Communication between peers uses WebRTC (DTLS/SCTP) for BBP and dedicated protocols for agent-based peering.
• All data within the cloud is encrypted at rest.
• Integration with front-end providers is implemented securely using a standard JSON Web Token mechanism to ensure that only authorized users have access to the requested data, there is no requirement for separate authentication services.

The ECDN platform is multi-tenant environment with all customer data tagged per organization to provide tenant isolation. This tagging persists through the data lifecycle and is enforced at every layer of the system, i.e. only requests processed within an authenticated organization’s context may access that organization’s data and these restrictions apply to all data and all processes/threads, both in memory and on disk. Using this mechanism access to other tenant data is not possible.

All software is developed by personnel in line with a Software Development Lifecycle policy. This includes strict quality steps including the requirement that all application code is scanned for vulnerabilities through industry standard best practice and auditing third-party tools and all application code is independently verified prior to deployment in a production environment.

DATA COMPLIANCE #

The following certifications with regards to security and data compliance are present:

• SOC 2 Type II Service Organization Control for Data Security

• GDPR Compliant – https://kollective.com/wp-content/uploads/2020/11/Controller-Processor-Addendum-V11052020.pdf
• Cloud Security Alliance STAR Level 1 Security Self-Assessment – https://cloudsecurityalliance.org/star/registry/kollective-technology

• The ECDN platform is hosted within Microsoft Azure and therefore we automatically inherit certifications of the Azure cloud such as ISO27001.

The ECDN does not store or source video content. Where content is unable to be sourced via an available peer then content is sourced directly from the integrating partner CDN without traversing the ECDN cloud service. In this way there is no sourcing or storage of content including personal images outside of the customer environment.

In addition, all content is encrypted by the integrating partner, (e.g. Microsoft), we do not own or have access to the keys in order to decrypt, we are only responsible for the distribution of the partner-encrypted content.

We provide multiple privacy controls for personal data as described in the “Managing Personal Data” section above.

Additional details can be found in the privacy policy at https://kollective.com/privacy-policy .

Operational Security

The ECDN’s operational personnel manage the platform inline with the Privacy Policy and Information Security Policy based on NIST. Strict operational processes govern all aspects of operational management including data security, network security, host security, monitoring, auditing, change control, etc. and the processes are independently audited and verified by SOC2 Type II certification.

Other functions managed by Operations team personnel include:

• Annual Independent penetration testing conducted using a 3rd party
• Weekly scans of the production environment to test ongoing vulnerability detection using automated tools.
• Security incident monitoring and reporting.
• Annual Business Continuity and Disaster Recovery testing.

There is no outsourcing of IT or security management functions, all processes are managed internally.

FREQUENTLY ASKED QUESTIONS #

APPLICATION FAQ #

What is the difference between Browser-Based Peering and Agent Based Peering?

Both solutions provide efficient delivery of content however the primary use cases for BBP are to support live video events or concurrent use video-on-demand. An agent-based approach can support additional use cases including local caching & distribution of Video-on-Demand and software deployment through Microsoft Endpoint Manager (Intune or Systems Center Configuration Manager).

Both BBP and agent-based peering support strict ECDN boundary and scale testing using the Network Readiness Test.

Can I utilize Browser-Based Peering and Agent Based Peering in My Company?

Yes, you can use either or both in a hybrid model, for example to utilize BBP for Live and the Agent for VoD.

Which browsers are supported for Browser Based Peering?

• Microsoft Teams Desktop Client – Windows, Mac
• Microsoft Windows – Microsoft Edge (Chromium), Chrome (79+), Firefox (72+)
• Mac – Safari (12+), Chrome (79+), Firefox (72+)
• Tablet – Safari (13.2+), Chrome Android (79+), Firefox Android (68+)
• Mobile – Chrome Android (79+), Firefox Android (68+)
• Mobile Teams Clients – Expected Q3 2021

Legacy browsers including Internet Explorer provide analytics about events but do not support the WebRTC digital channel that is used by the ECDN for Browser Based Peering. An agent-based deployment supports peering with legacy browsers.

What are the common ports and protocols?

• Communication to the the ECDN’s cloud applications use HTTPS
• BBP communication between peers uses WebRTC (DTLS/SCTP), UDP-based, with port ranges defined by browser policy.
• Agent-based communication between peers uses TCP+SSL by default on port 31016.

Does the platform support IPv6?

Yes

What happens if a user can’t communicate with other peers?

The machine will fall back to the CDN to retrieve content.

How does the Peering interoperate with Adaptive Bitrate control?

The ECDN natively supports the ABR model, with additional capabilities to filter out undesirable bitrates on a location-by-location basis.

How can the event delivery be validated and understood?

The customer portal provides near real-time analytics to display key metrics including bandwidth savings, peering efficiencies etc.

Can I view platform availability?Yes, this is available by independent 3rd party monitoring via https://status.kollective.app/ where it is also possible to subscribe to automatic status updates.

PERFORMANCE FAQ #

What is the expected time to first frame (start time) for users viewing for a live event?

Typically 2-5 seconds, comparable to a native connection that does not use an ECDN.

In the ECDN how many machines does each machine serve content to?

Connectivity is controlled centrally by an administrative policy that the ECDN manages. Each machine within the mesh establishes relationships with a defined number of other machines in the same and upper/lower tiers.

DEPLOYMENT FAQ #

What are the configuration pre-requisites to enable the ECDN platform?A self-service portal is provided at https://portal.kollective.app/free-trial that provisions the required configuration including tokens for 3rd party integration.What firewall or proxy changes are required in my environment?

All communication with the ECDN’s cloud are HTTPS, in most environments no changes are required.

Does the ECDN support the use of WebRTC mDNS anonymization?

Yes, however we recommend disabling anonymization of local IP address via simple GPO policy for optimal peering which enables private IP advertising to specific URLs thereby avoiding risk of leaking the IP address to the Internet.

A separate technote is provided at Kollective University that describes mDNS and IP Anonymization best practices.

An agent deployment does not requirement any mDNS configuration.

Do I need to install an agent or any other software?

No dependent on use case, an agent is not required for video-only ECDN.

SECURITY Q&A #

What is being downloaded to the browser?

The javascript plugin in which peering is implemented is downloaded from cdn.kollective.app using secure protocols. It is approximately 800kb in size and once retrieved is stored in the browser cache for future use until the cache is refreshed or the peer mesh client is upgraded.

How does the ECDN interact with my endpoint security or other agents including anti-virus?

Browser-Based Peering operates within the a compliant browser and therefore does not typically interact with endpoint security.

In some environments an agent may require whitelisting.

How is content secured from unauthorized access?

The authorization mechanism is implemented within the front-end application. A JWT process extends the authorization to the ECDN.

Does the ECDN have access to my content?

No, the encrypted content is sourced directly from the CDN. The ECDN does not have, receive, process or store content, nor are able to decrypt the streams.

How is the peering secured?

The protocol itself is built on top of trusted and well-defined network protocols including DTLS/SCTP (BBP) and TCP+SSL (agent) for secure connections between nodes. TLS with authenticated tokens are used for connections to cloud services.

Who has access to my data?

Operational personnel manage the ECDN platform inline with the procedures defined within the SOC2 certification process and privacy policy. The ECDN does not have access to the customer content and no Personally Identifiable Information (PII) data is stored by the ECDN for event analytics.

Is a SOC2 certification report published?

Yes, under NDA we are happy to share additional security documentation including the SOC2 certification report, a more detailed security overview and copies of the Information Security Policy, Business Continuity Plan and Software Development Lifecycle.