TABLE OF CONTENTS

• Introduction

Introduction

This article consists of a list of "bullet points" specifying the various security measures that the ShedEx solutions has implemented as well as the processes to continually maintain a secure transfer of potentially sensitive scheduling data.

• All controlled communications within the system are performed over HTTPS.
• All scheduling system communication happens entirely within the customer’s internal network. The Desktop Client and Autonomous Component communicate with the scheduling systems locally within the tenant environment. Cloud components hosted in Azure, outside the tenant network, never initiate communication with the scheduling system servers.
• Uploaded data is short-lived and protected using encryption and digital signing based on private/public key pairs shared between the tenants involved in the transfer.
• Data retention and deletion can be controlled by the tenant. The recommended configuration is immediate deletion after processing whenever possible.
• API endpoints are designed with tenant isolation in mind to ensure that one tenant’s data cannot be accessed or viewed by another tenant unless explicitly required by the business logic.
• Access to data and functionality is restricted based on user roles and permissions. All API endpoints enforce the necessary authorization and permission checks.
• The application currently supports authentication through Microsoft Entra ID only. This helps ensure that unauthorized users cannot access the system.
• It may also be useful to mention that security controls are implemented across both the application and API layers to help maintain secure communication, authentication, and tenant-level data separation.
• Cloud infrastructure is hosted on Microsoft Azure, leveraging Azure’s built-in security and compliance capabilities.
• Sensitive credentials, secrets, and connection information are securely stored and managed through centralized secret management solution in Azure Key Vault.
• Authentication tokens and user sessions are managed through Microsoft Entra ID security standards, including support for MFA policies configured by the tenant.
• Communication between system components uses authenticated and authorized APIs only.
• The system is designed following least-privilege access principles, where users and services only receive the permissions necessary for their roles.
• Error handling and logging are designed to avoid exposing sensitive internal system information to end users.
• Security improvements and updates are continuously evaluated as part of ongoing product maintenance and development.
• Independent third-party security penetration tests are conducted annually to help ensure the security, stability, and resilience of the system against potential cyber threats and unauthorized access attempts.