Application security and access control.

1. Summary

• Your data stays in your SharePoint. The apps have no database or server-side component of their own that would process the data. The data lives in SharePoint lists and libraries in your Microsoft 365 tenant, where you can classify, back up and govern it like any other content.
• No separate sign-in. The apps run as SharePoint web parts (SharePoint Framework) under the identity of the signed-in user and have only the rights that user has.
• You control the roles. Roles are SharePoint groups into which you add people or Entra ID groups. Access to data is enforced by SharePoint, not just by the user interface.
• Delegated permissions only. The apps always call Microsoft Graph on behalf of the signed-in user. None of the SharePoint apps requires application (app-only) access.
• No tracking. The apps contain no third-party analytics or tracking tools.
• Only static code is downloaded from us. Our distribution network serves the app code, fonts, licence files and guided-tour voice recordings. Every version is first released so that it does not reach customers and is verified in our own environment; only then is it released to production.

2. Trust boundaries

Boundary	Protection
browser ↔ SharePoint and Microsoft Graph	identity of the signed-in user, TLS
browser ↔ EasyPortal 365 distribution network	TLS, download of static files only; the apps verify the signature and checksum of the code (section 6)
browser ↔ public services (some apps only)	TLS, only the listed services and only the data stated in section 4.2

Your Microsoft 365 tenant forms one trust domain that you manage. The only permanent external component is our distribution network. The only things that reach us are a bug-report e-mail the user sends themselves and – only if you turn it on – the data of the optional Connectors service (4.2).

3. Sign-in, roles and permissions

3.1 The user towards SharePoint and Microsoft Graph

The apps run in the context of a SharePoint page under the signed-in user, just like other extensions in your tenant. They have no user accounts, passwords or app registration in Entra ID of their own. Whatever the user may not do in SharePoint, they may not do in the app either.

Outside SharePoint the apps use Microsoft Graph with delegated permissions, e.g. to send a notification e-mail from the user’s mailbox or to check group membership. You see the exact permissions of each app when you approve them in the SharePoint admin center. A delegated permission never grants more than the user already has: for example, only a user who holds the relevant role can manage groups in Entra ID.

A platform behaviour worth knowing: Microsoft Graph permissions approved in the SharePoint admin center (API access) are bound to the shared tenant principal SharePoint Online Client Extensibility Web Application Principal. They are therefore available to all SharePoint Framework solutions in your app catalog, not just to our app. Approving them is a tenant-level decision that belongs to your app catalog governance. A permission that is not approved does not break the app; it only disables the feature that needs it.

3.2 Roles

• Roles are SharePoint groups that the app creates on its site at first run (e.g. administrators, contributors, readers – the specific roles are described in the app documentation).
• You decide the members. They can be people as well as Entra ID groups, including dynamic groups based on user attributes (department, job title, location). If you want roles to follow Entra ID attributes, simply add such a dynamic group to the role.
• The app keeps no user or role table of its own. It determines the user’s role from membership in SharePoint groups and, for nested Entra ID groups, via Microsoft Graph.

3.3 Who can reach the data

• SharePoint enforces access. Lists with sensitive data have their own permissions (inheritance from the site is broken) and each role gets only the access it needs. The default site groups Members and Visitors can be removed from sensitive lists completely.
• Item-level protection. Where an app promises it (e.g. “everyone sees only their own records”), SharePoint enforces it – either with permissions directly on the item or with a list setting under which everyone reads only the items they created.
• Append-only lists. Logs and registers can be set up so that regular users can add entries but cannot change or delete them.
• The user interface only hides, by role, the functions a user is not allowed to use anyway. Where a restriction is only a filter in the app, the app documentation says so explicitly.
• Site owners and site collection administrators always have full access to all data on the site in SharePoint. We therefore recommend keeping this circle as small as possible and placing apps with sensitive data on a dedicated site.

4. Data

4.1 Storage

• All app data is stored in SharePoint lists and libraries on the app’s site. Where it makes sense, the lists are hidden from Site contents so that users do not work with them outside the app. Hiding is about clarity; access is governed by permissions.
• Your Microsoft 365 settings apply to the data: data residency, backup, retention policies, sensitivity labels, eDiscovery and data loss prevention (DLP).
• Statistics of calls to the SharePoint and Microsoft Graph APIs (call counts and throttling by request type, no content) are stored in a list on the same site. None of it leaves the tenant.

4.2 What leaves your tenant

When	Where	What
a user sends an e-mail from the app (notification, copy of a record)	the recipient chosen by the app according to its settings, or by the user	the e-mail content; it is sent from the user’s mailbox through Microsoft 365 and stays in their Sent Items
a user reports a bug or suggests an improvement	EasyPortal 365 support (support@easyportal365.com); sent from the user’s mailbox and stays in their Sent Items	report text and attachments, severity, app name and version, user name and e-mail, tenant ID, site address, browser type and time
loading the app	EasyPortal 365 distribution network	nothing is sent; the browser downloads static files (code, fonts, licence file, guided-tour recordings)
CRM, Received documents – company lookup	ARES (Czech Ministry of Finance business register)	company ID number only
Fleet – address search	Nominatim, Photon	the address text searched for
Fleet – map	OpenStreetMap (map tiles), unpkg.com (map library styles)	the map area displayed
Workplace – weather (optional)	Open-Meteo	town name and coordinates
Workplace – industry news (optional)	a public RSS feed via the public proxies allorigins.win or r.jina.ai	the address of the public feed only
Controlled documents – strict confirmation mode (optional)	api.ipify.org	nothing; the service returns the user’s public IP address for the confirmation record
Atlas – Microsoft 365 roadmap	EasyPortal 365 service (Azure, West Europe)	nothing; only public information about Microsoft 365 updates is downloaded
CRM, Worklog, Marketing, Workplace, Company multimedia centre, My Documents – AI features (only with AI Assistant deployed)	the AI Assistant service in your Azure subscription	the query text and source material; described in the AI Assistant security document
Workplace, Company multimedia centre – embedded video	YouTube, Vimeo	standard browser data, only if the content contains a video
CRM – Mailchimp integration (optional)	EasyPortal 365 Connectors service (Azure, West Europe) and Mailchimp	contact data synchronised with Mailchimp; the service stores only an encrypted access token and details of the connected account

With every transfer the browser passes the usual technical data (IP address, browser type). The licence check uses only a hash of the tenant ID, no user data. Processing in the case of the Connectors service is governed by Article 10 of the terms and conditions (section 8).

4.3 Records and audit trail

• Microsoft 365 audit log (Microsoft Purview). Because the data lives in SharePoint, the standard Microsoft 365 audit log records the creation, modification and deletion of items and file operations including file access. From there you can forward it to your log management tool (SIEM) via the Office 365 Management Activity API or the connectors these tools usually provide. Merely viewing a list item (without opening a file) is not recorded in the log. Retention in Microsoft 365 depends on your licence.
• Version history. Registers have versioning turned on, so every item shows who changed what and when.
• App logs. Apps where it matters keep their own change log in a list to which regular users can only add entries.
• The apps run in the browser and have no server-side component, so they do not write to syslog themselves. The route to central log management is the Microsoft 365 audit log.

5. Installation and administration

• Installation requires a SharePoint administrator: uploading the installation package to the app catalog and approving the Microsoft Graph permissions (API access).
• First run is performed by a site owner: the app creates its lists, groups and permissions. A regular user cannot perform these steps.
• Teams. Apps with Teams support use the same code and the same permissions. In Teams an app only reads and writes data; it does not create lists or configuration.
• Uninstalling. Removing an app does not delete data on the site. Permissions approved in API access must be revoked manually in the SharePoint admin center – this is how the platform works.

6. Code distribution and integrity

• App code is loaded from the EasyPortal 365 distribution network (cdn.easyportal365.cz) and runs in the user’s browser with the user’s rights. The distribution network contains static files only; it has no access to your tenant and stores nothing that comes from you.
• Versions are released in a controlled way. A new version is first published so that it does not reach you and is verified in our own environment. Only the production release makes it available to customer sites, which run the latest production version. On request we can hold your site on a specific version or roll it back to the previous one.
• Signature and checksum verification. The apps accept only a version listed in our signed release list and load every code file with a checksum (Subresource Integrity). The browser refuses to run a forged or altered file.
• Only one account can write to the distribution network, two-factor authentication is enforced for the organisation and rewriting the history of the main branch is blocked.
• Third-party libraries are bundled in our packages and we host fonts ourselves. The apps do not load code from public CDNs; the only exception is the map library styles in Fleet (unpkg.com).

7. How we develop the apps

7.1 Code and its management

• The source code is kept in private GitHub repositories; two-factor authentication is enforced for the organisation.
• Before every change is saved, an automated check makes sure that customer names do not get into the repositories; in the documentation and distribution network repositories it also blocks invisible and bidirectional Unicode characters (protection against Trojan Source attacks).
• Before files are published to the distribution network, a check goes through exactly the files about to be published and stops the publication if they contain customer data.

7.2 Quality gates that block a release

• TypeScript in strict mode (strict) and ESLint focused on real defects (e.g. unhandled asynchronous operations). The number of rule exceptions may only go down.
• Automated tests run with every release build; a failing test stops the release.
• Security and logic guards (dozens of checks in every app, some of them app-specific), for example:
  • a list that promises restricted access really has it configured,
  • every panel and every action passes a role check,
  • unreadable data is never treated as “empty” and never overwrites existing records,
  • change history never claims “no changes” when it could not be loaded.

7.3 Secure coding principles

• Content from SharePoint is untrusted input. Formatted text from the apps’ editors passes through a shared sanitiser with an allowlist of elements only. Content of SharePoint pages and items is stripped of scripts, dangerous elements and event-handler attributes, and links and styles are let through only from allowed schemes and properties.
• Permissions are enforced in SharePoint, not just in the interface; role checks cover every entry point of an app.
• A failed write is an error. An app does not report success when SharePoint rejected a write, and destructive operations work only with data that has been verifiably loaded.
• No secrets in browser code. The app code contains no passwords, keys to customer data or access tokens.
• Regular security reviews of the whole fleet and of individual apps; we verify findings against the code, fix them and track them in a technical-debt register with a unique identifier until closed.

7.4 Releases and fixes

• Every version goes through a build with tests and guards, is first published without any impact on customers and is verified in our environment.
• A new release series is issued only on a management decision; customers see the changes in the “What’s new” section directly in the app.
• Updates that we mark as security, critical or mandatory must be installed and used by the customer (terms and conditions, Article 6).

8. Contractual framework

• Supplier: accelapps s.r.o., Hvězdova 1716/2b, Nusle, 140 00 Prague 4, Czech Republic, company ID 066 28 362, registered with the Municipal Court in Prague, section C, file 285754.
• The terms and conditions are part of every order. Article 10 contains the data processing agreement under Article 28(3) GDPR. In the default model the apps run in your environment and we do not host the data; where we do process data (e.g. the Connectors service or support with access to your environment), this article applies. The terms and conditions are issued in Czech.
• Our access to your environment is possible only through an account you set up for us for implementation or support. You control its scope and validity.
• Support: support@easyportal365.com, working days 9:00–16:00 CET; we confirm receipt of a request within two working days.

9. Deployment recommendations

1. Put apps with sensitive data on a dedicated site and apply a sensitivity label according to your classification.
2. Keep the circle of site owners and site collection administrators as small as possible – they have access to all data.
3. Add Entra ID groups to roles, ideally dynamic ones, so that access changes as employees join, move or leave.
4. Approve Microsoft Graph permissions deliberately – they apply to all SharePoint Framework solutions in the tenant (3.1).
5. Connect the Microsoft 365 audit log to your log management (4.3).
6. Restrict or remove the supplier’s implementation account once implementation is complete.

10. Mapping to the OWASP Top 10:2025

The overview follows the web application risks of the OWASP Top 10:2025. AI Assistant additionally maps to the OWASP Top 10 for LLM Applications in its own security document.

Risk	How it is addressed
A01 Broken Access Control	access to data is enforced by SharePoint (dedicated list permissions, item-level protection), not by the user interface; roles are SharePoint groups that you control; role checks cover every entry point of an app, and guards verify at every build that a list promising restricted access really has it configured (3.3, 7.2)
A02 Security Misconfiguration	the app creates its lists, groups and permissions itself at first run according to its definition, with no manual setup; the default site groups Members and Visitors can be removed from sensitive lists; recommended tenant settings are in section 9
A03 Software Supply Chain Failures	third-party libraries are bundled in our packages with locked versions; the apps do not load code from public CDNs; the code is verified by signature and checksum; only one account with enforced two-factor authentication can write to the distribution network (6)
A04 Cryptographic Failures	all connections use TLS; the apps store no passwords or secrets of their own; encryption of data at rest is provided by Microsoft 365; the release list is signed (6)
A05 Injection	content from SharePoint is untrusted input and reaches the page only through a shared sanitiser; links and styles only from allowed schemes and properties (7.3)
A06 Insecure Design	no server-side component or database of our own; delegated permissions only; the access boundary lies in the platform, not in app code; regular security reviews (1, 7.3)
A07 Authentication Failures	the apps have no sign-in or passwords of their own; sign-in is handled by Entra ID including multi-factor authentication and Conditional Access, which you configure (3.1)
A08 Software or Data Integrity Failures	code signature and checksum; every version is first verified in our environment; unreadable data is never treated as empty and never overwrites existing records; destructive operations work only with verifiably loaded data; version history for registers (6, 7.2, 7.3, 4.3)
A09 Security Logging and Alerting Failures	operations are recorded in the Microsoft 365 audit log, which you forward to your SIEM and on which you set up alerts in Microsoft Purview; the apps keep their own logs to which regular users can only add entries (4.3)
A10 Mishandling of Exceptional Conditions	a write rejected by SharePoint is reported as an error, never as success; a read failure is never mistaken for empty data; change history never claims “no changes” when it could not be loaded (7.2, 7.3)

11. Mapping to ISO/IEC 27001:2022 (selection)

Area (Annex A)	Where in the solution
5.15 / 5.18 Access control and access rights	user identity, roles as SharePoint groups, permissions enforced by SharePoint (3)
5.19–5.22 Supplier relationships	contractual framework, processing of personal data under Article 28 GDPR, our access only through an account you control (8)
5.23 Information security for use of cloud services	data in your Microsoft 365 tenant under your policies (4.1)
8.2 Privileged access rights	site owners and site collection administrators, installation only by a SharePoint administrator (3.3, 5)
8.3 Information access restriction	list permissions, item-level protection, append-only lists (3.3)
8.4 Access to source code	private repositories, enforced two-factor authentication (7.1)
8.9 Configuration management	permissions and lists created according to the app’s definition (5)
8.12 Data leakage prevention	data stays in the tenant, your DLP and sensitivity labels apply; flows outside the tenant are listed (4.1, 4.2)
8.15 / 8.16 Logging and monitoring	Microsoft 365 audit log, version history, app logs (4.3)
8.24 Use of cryptography	TLS on all connections, signed release list, code checksums (6)
8.25 / 8.28 Secure development and coding	strict TypeScript, input sanitisation, guards and tests as a release gate (7)
8.29 Security testing	automated tests and regular security reviews with tracked findings (7.2, 7.3)
8.32 Change management	releases first without customer impact, verification, then production release; the option to hold a version (6, 7.4)

12. Known limitations

We state them openly because decisions are based on them. They are properties of the platform, not defects that could be fixed in the app.

#	Limitation	What to do about it
1	Site owners and site collection administrators always have access to all data on the site in SharePoint	put apps with sensitive data on a dedicated site and keep this circle as small as possible
2	Approved Microsoft Graph permissions are available to all SharePoint Framework solutions in the tenant	approve deliberately and watch what is uploaded to the app catalog
3	Merely viewing a list item is not recorded in the Microsoft 365 audit log	for sensitive registers, rely on versions and app logs; store documents as files, whose opening is recorded
4	A restriction that is only a filter in the app is not a permission	the app documentation names such places explicitly; where a boundary is needed, set permissions in SharePoint
5	App code runs in the signed-in user’s browser and is loaded from our distribution network. Anyone who managed to forge our code would gain at most what that user can access	code signature and checksum, a single account with write access to the distribution network, two-factor authentication (6)
6	Removing an app does not revoke approved Microsoft Graph permissions	revoke them manually in the SharePoint admin center (5)

13. References

• OWASP: OWASP Top 10:2025
• Microsoft: Audit log activities · Office 365 Management Activity API

Version 1.0 · 11 November 2026 · issued by accelapps s.r.o., company ID 066 28 362. Questions: support@easyportal365.com.