PadelOS brengt spelers, trainers, administrators, managers, clubs, locaties, banen, lessen, planningen, evaluaties, facturen en betalingen samen in één digitale werkomgeving. Zodra verschillende gebruikers met persoonsgegevens en bedrijfsgegevens werken, zijn betrouwbare accounts, duidelijke bevoegdheden en goede informatiebeveiliging onmisbaar.
De module Accounts, Rollen & Security bepaalt:
Wie toegang krijgt tot PadelOS.
Hoe de identiteit van een gebruiker wordt gecontroleerd.
Welke gegevens een gebruiker mag bekijken.
Welke gegevens een gebruiker mag toevoegen, wijzigen, exporteren of verwijderen.
Hoe handelingen worden vastgelegd en gecontroleerd.
Hoe persoonsgegevens volgens de AVG worden beschermd.
Hoe incidenten, fouten en verloren toegang worden afgehandeld.
PadelOS wordt stapsgewijs ontwikkeld. De huidige basis maakt gebruik van Google Apps Script, Google Sheets en een webportaal dat onder meer via Google Sites kan worden aangeboden. Deze omgeving is geschikt voor ontwikkeling, demonstraties en gecontroleerde pilots. Voor grootschalig professioneel gebruik is een uitgebreidere beveiligingsarchitectuur nodig, met centrale identiteitscontrole, tenantisolatie, versleuteling, logging, monitoring en formeel privacybeheer.
De beveiligingsvisie van PadelOS is gebaseerd op het uitgangspunt:
Iedere gebruiker krijgt uitsluitend toegang tot de gegevens en handelingen die noodzakelijk zijn voor de eigen taak, rol, organisatie en relatie met PadelOS.
Beveiliging is daarbij geen losse functie die achteraf wordt toegevoegd. Accounts, rollen, gegevensstructuren, API’s, formulieren, exports en koppelingen moeten vanaf het ontwerp volgens dezelfde veiligheidsprincipes werken.
De belangrijkste uitgangspunten zijn:
Privacy by design: privacy wordt al tijdens het ontwerpen meegenomen.
Privacy by default: standaardinstellingen zijn zo terughoudend mogelijk.
Least privilege: iedere gebruiker krijgt zo weinig mogelijk rechten.
Need to know: gegevens zijn alleen zichtbaar wanneer ze voor de taak nodig zijn.
Separation of duties: gevoelige handelingen kunnen over meerdere rollen worden verdeeld.
Zero trust: iedere aanvraag wordt gecontroleerd, ook binnen een bestaande sessie.
Defense in depth: meerdere beveiligingslagen beschermen dezelfde gegevens.
Traceerbaarheid: belangrijke acties worden in een auditlog geregistreerd.
Tenantisolatie: organisaties mogen elkaars gegevens niet kunnen inzien.
Herstelbaarheid: gegevens, accounts en configuraties moeten veilig kunnen worden hersteld.
Het uiteindelijke doel is een betrouwbare PadelOS-werkruimte waarin gebruikers eenvoudig kunnen werken zonder dat veiligheid onnodig ingewikkeld wordt.
Veel sportorganisaties werken met losse spreadsheets, gedeelde accounts, WhatsApp-groepen, e-mailbijlagen en verschillende agenda’s. Hierdoor ontstaan risico’s:
Onbekend is wie welke gegevens heeft bekeken of gewijzigd.
Meerdere mensen gebruiken hetzelfde account.
Oud-medewerkers behouden mogelijk toegang.
Spelerslijsten worden zonder duidelijke noodzaak geëxporteerd.
Telefoonnummers en e-mailadressen worden breder gedeeld dan noodzakelijk.
Persoonsgegevens staan verspreid over verschillende bestanden.
Verwijderingen en wijzigingen zijn niet altijd herstelbaar.
Rechten worden handmatig en inconsistent toegekend.
Rollen binnen een club veranderen zonder dat toegang wordt aangepast.
Gegevens van verschillende clubs kunnen onbedoeld worden vermengd.
Beveiligingsincidenten worden niet centraal geregistreerd.
Toestemming, bewaartermijnen en verwijderverzoeken zijn moeilijk aantoonbaar.
PadelOS lost dit op door identiteit, rollen, relaties, toegangsrechten en logging centraal te organiseren. Een account krijgt geen toegang omdat iemand toevallig een link bezit, maar omdat de gebruiker aantoonbaar bij een organisatie, profiel en geldige rol hoort.
De beveiligingsarchitectuur ondersteunt verschillende gebruikers en belanghebbenden.
Gebruikers
Administrators
Managers
Trainers
Spelers
Viewers
Clubbestuurders
Locatiebeheerders
Financiële medewerkers
Vrijwilligers
Externe samenwerkingspartners
Professionele betrokkenen
Softwareontwikkelaars
Securityspecialisten
Functionarissen voor gegevensbescherming
Privacyadviseurs
Verwerkers en subverwerkers
Accountants en administrateurs
Hosting- en integratiepartners
Investeerders en pilotorganisaties
Niet iedere doelgroep krijgt dezelfde toegang. PadelOS combineert de rol van een gebruiker met de organisatie, het profiel, de module, het record en de gevraagde handeling.
Een account is de digitale identiteit waarmee iemand toegang krijgt tot PadelOS. Een account is niet hetzelfde als een persoon, speler of trainer.
PadelOS maakt onderscheid tussen:
PERSOON: de centrale persoonsgegevens.
GEBRUIKER: het account waarmee iemand kan inloggen.
PROFIEL: de functionele hoedanigheid, zoals speler of trainer.
ORGANISATIE: de club, padelschool, stichting of samenwerkingspartner.
LIDMAATSCHAP: de relatie tussen persoon en organisatie.
ROL: de verzameling bevoegdheden binnen een bepaalde context.
SESSIE: de tijdelijke geldige toegang na authenticatie.
TOESTEMMING: een vastgelegde privacykeuze van de persoon.
Eén persoon kan meerdere profielen hebben. Stijn Gabeler kan bijvoorbeeld binnen één organisatie Trainer zijn en binnen een andere context Manager of Administrator. Deze rollen mogen niet automatisch overal dezelfde toegang geven.
Een account kan de volgende statussen hebben:
Uitgenodigd
Registratie gestart
In afwachting van verificatie
Actief
Tijdelijk geblokkeerd
Wachtwoordherstel vereist
Opgeschort
Uit dienst of uitgeschreven
Gearchiveerd
Verwijderd of geanonimiseerd
Door personen, accounts en profielen van elkaar te scheiden, blijven gegevens beheersbaar wanneer een rol of organisatie verandert.
De Administrator beheert de technische en organisatorische inrichting binnen de eigen toegestane omgeving. Mogelijke bevoegdheden zijn:
Accounts uitnodigen, activeren en blokkeren.
Rollen en rechten toekennen.
Modules en tabellen beheren.
Organisatiegegevens instellen.
Auditlogs bekijken.
Imports en exports uitvoeren.
Gegevenscorrecties en herstelacties uitvoeren.
Privacyverzoeken administreren.
Integraties en API-toegang beheren.
Een Administrator heeft niet automatisch onbeperkte toegang tot iedere tenant. Een organisatie-administrator beheert uitsluitend de eigen organisatie. Platformbeheer moet als afzonderlijke, zwaarder beveiligde rol worden ingericht.
De Manager coördineert de dagelijkse operatie:
Spelers en trainers beheren.
Trainingsgroepen samenstellen.
Lessen en banen plannen.
Aanwezigheid en capaciteit controleren.
Rapportages bekijken.
Organisatiegebonden communicatie voorbereiden.
Facturen of betalingen beheren wanneer dit is toegestaan.
Een Manager hoeft niet automatisch wachtwoorden, beveiligingsinstellingen of volledige auditlogs te kunnen beheren.
De Trainer krijgt toegang tot gegevens die nodig zijn voor lesgeven en begeleiden:
Eigen planning bekijken.
Toegewezen spelers en teams bekijken.
Lessen voorbereiden.
Aanwezigheid registreren.
Evaluaties en leerdoelen vastleggen.
Oefeningen en leskaarten gebruiken.
Relevante contactgegevens bekijken als daarvoor een grondslag bestaat.
Een Trainer hoort geen volledige financiële administratie, accountbeheer of spelers van andere organisaties te kunnen zien.
De Speler krijgt voornamelijk toegang tot het eigen profiel:
Eigen persoonsgegevens bekijken.
Toegestane gegevens wijzigen.
Eigen lessen en planning bekijken.
Aan- of afwezigheid doorgeven.
Eigen voortgang, evaluaties en documenten bekijken.
Privacykeuzes beheren.
Een inzage-, correctie- of verwijderverzoek indienen.
Een speler mag gegevens van andere spelers alleen zien wanneer dit noodzakelijk en expliciet toegestaan is, bijvoorbeeld de naam van teamgenoten binnen een trainingsgroep.
De Viewer heeft uitsluitend leesrechten voor expliciet geselecteerde onderdelen. Deze rol kan worden gebruikt voor:
Bestuursleden die rapportages mogen bekijken.
Externe adviseurs.
Auditors.
Demonstratieaccounts.
Tijdelijke projectpartners.
De Viewer kan geen records wijzigen, verwijderen of exporteren, tenzij daarvoor afzonderlijk een beperkte bevoegdheid wordt toegekend.
PadelOS gebruikt uiteindelijk een combinatie van Role-Based Access Control en Attribute-Based Access Control.
Role-Based Access Control bepaalt wat een algemene rol mag doen. Attribute-Based Access Control controleert aanvullende kenmerken, zoals:
Tenant of organisatie.
Club of locatie.
Eigenaar van het record.
Toegewezen trainer.
Trainingsgroep.
Leeftijdscategorie.
Status van het account.
Contractuele relatie.
Tijdstip of geldigheidsperiode.
Gevoeligheidsniveau van de gegevens.
Expliciete toestemming.
Doel waarvoor de gegevens worden gebruikt.
Rechten kunnen op verschillende niveaus worden toegekend:
Niveau
Voorbeeld
Platform
Platformbeheer en algemene configuratie
Tenant
Toegang tot één padelschool of organisatie
Organisatie
Beheer van een specifieke club
Locatie
Alleen gegevens van een bepaalde locatie
Module
Wel Planning, niet Facturatie
Tabel
Wel SPELERS, niet GEBRUIKERS
Veld
Wel naam, niet medische informatie
Record
Alleen toegewezen spelers
Handeling
Lezen, maken, wijzigen, verwijderen of exporteren
Eigendom
Alleen het eigen profiel
Tijd
Tijdelijke toegang tijdens een project
De standaardhandelingen zijn:
Create
Read
Update
Delete
Export
Import
Approve
Assign
Archive
Restore
Share
Manage permissions
Een gebruiker die een record mag bekijken, mag dit dus niet automatisch wijzigen, verwijderen of exporteren.
Registratie kan plaatsvinden via:
Een uitnodiging van een Administrator.
Een uitnodiging van een club of padelschool.
Zelfregistratie met goedkeuring.
Een bestaand spelers- of trainersprofiel.
Een beveiligde externe identiteitsprovider.
Een migratie vanuit een bestaand systeem.
De aanbevolen registratiestroom is:
De organisatie verstuurt een uitnodiging.
De gebruiker opent een eenmalige beveiligde link.
Het e-mailadres wordt geverifieerd.
De gebruiker accepteert de gebruiksvoorwaarden.
Verplichte privacyinformatie wordt getoond.
Eventuele toestemmingen worden afzonderlijk gevraagd.
Het account wordt aan de juiste persoon en organisatie gekoppeld.
De gebruiker stelt een veilige authenticatiemethode in.
De toegekende rol wordt gecontroleerd.
De activatie wordt in het auditlog vastgelegd.
Een activatielink moet tijdelijk geldig en slechts eenmaal bruikbaar zijn. Foutmeldingen mogen niet onthullen of een bepaald e-mailadres al in het systeem voorkomt.
Bij minderjarige spelers is extra aandacht nodig voor vertegenwoordiging, ouderlijke toestemming, informatievoorziening en de juridische grondslag van de verwerking.
Tijdens de huidige pilotfase kan PadelOS gebruikmaken van Google-accountidentiteit, Apps Script-sessies of een beperkte eigen accountlaag. Voor professioneel gebruik moet authenticatie worden ondergebracht bij een gespecialiseerde identiteitsvoorziening.
De gewenste mogelijkheden zijn:
E-mailverificatie.
Veilige wachtwoorden.
Wachtwoordloze login via beveiligde link.
Single Sign-On.
Google- of Microsoft-login.
Multi-factor-authenticatie.
Herstelcodes.
Controle op verdachte inlogpogingen.
Tijdelijke blokkering na herhaalde fouten.
Waarschuwing bij een nieuwe login of nieuw apparaat.
Extra verificatie voor gevoelige handelingen.
Voor Administrators, financiële rollen en platformbeheerders hoort multi-factor-authenticatie verplicht te zijn.
Na succesvolle authenticatie controleert PadelOS nog steeds:
Of het account actief is.
Of de rol nog geldig is.
Of de gebruiker toegang heeft tot de tenant.
Of de organisatie actief is.
Of de gevraagde handeling is toegestaan.
Of aanvullende verificatie nodig is.
Inloggen bewijst de identiteit, maar geeft niet automatisch toegang tot alle gegevens.
PadelOS mag wachtwoorden nooit leesbaar opslaan. Wanneer PadelOS zelf wachtwoorden verwerkt, moeten deze worden beveiligd met een modern, speciaal voor wachtwoorden ontwikkeld hashing-algoritme, unieke salts en passende kosteninstellingen.
Daarnaast gelden de volgende uitgangspunten:
Geen wachtwoorden in Google Sheets.
Geen wachtwoorden in broncode.
Geen API-sleutels in frontend-HTML.
Geen geheime tokens in URL’s of exports.
Geen verzending van wachtwoorden per e-mail.
Geen gedeelde administratoraccounts.
Geen hergebruik van tijdelijke wachtwoorden.
Beveiligde opslag van secrets buiten de applicatiecode.
Regelmatige rotatie van gevoelige sleutels.
Intrekking van tokens bij accountblokkering of incidenten.
Een professioneel cloudplatform gebruikt bij voorkeur een gespecialiseerde identity provider. Hierdoor hoeft PadelOS zelf zo weinig mogelijk wachtwoordgegevens te verwerken.
Na het inloggen ontvangt een gebruiker een tijdelijke sessie. Deze sessie moet veilig worden beheerd.
Belangrijke maatregelen zijn:
Korte geldigheidsduur voor gevoelige accounts.
Automatische beëindiging na langdurige inactiviteit.
Veilige, niet via JavaScript uitleesbare cookies waar technisch mogelijk.
Bescherming tegen sessiediefstal en cross-site-aanvallen.
Vernieuwing van sessietokens.
Uitloggen op alle apparaten.
Intrekken van actieve sessies na een wachtwoordwijziging.
Registratie van apparaattype en globale logininformatie.
Herbevestiging van identiteit bij exports of rechtenwijzigingen.
Gebruikers moeten kunnen zien welke sessies actief zijn en onbekende sessies kunnen beëindigen. Exacte locatiegegevens moeten alleen worden opgeslagen als dat noodzakelijk, proportioneel en duidelijk uitgelegd is.
Een gebruiker krijgt toegang via gecontroleerde relaties tussen:
GEBRUIKERS
PERSONEN
PERSOON_PROFIELEN
GEBRUIKER_PERSONEN
ORGANISATIES
ORGANISATIE_PERSONEN
SPELERS
TRAINERS
CLUBS
LOCATIES
TEAMS
TRAININGSGROEPEN
Een Trainer-account kan bijvoorbeeld alleen spelerrecords openen wanneer:
Het account aan de juiste persoon is gekoppeld.
Die persoon een actief Trainer-profiel heeft.
De trainer bij de betreffende organisatie hoort.
De speler bij dezelfde toegestane organisatie hoort.
De speler of groep aan de trainer is toegewezen.
De gevraagde gegevens nodig zijn voor de trainersrol.
De gewenste handeling binnen de rechten valt.
Deze controles moeten door de backend worden uitgevoerd. Het verbergen van een knop in de frontend is geen beveiliging. Een gebruiker mag een verboden handeling ook niet rechtstreeks via een API-aanvraag kunnen uitvoeren.
PadelOS registreert belangrijke gebeurtenissen in een auditlog. Voorbeelden zijn:
Inloggen en uitloggen.
Mislukte inlogpogingen.
Accountactivatie en blokkering.
Wijzigingen van rollen en rechten.
Bekijken van bijzonder gevoelige gegevens.
Aanmaken, wijzigen, archiveren en verwijderen van records.
Imports en exports.
Downloaden van spelerslijsten.
Wijzigingen in facturen en betalingen.
Herstelacties.
API-gebruik.
Wijzigingen van privacykeuzes.
Afhandeling van AVG-verzoeken.
Beveiligingsincidenten.
Een auditrecord kan bevatten:
Unieke gebeurtenis-ID.
Datum en tijd.
Gebruiker en account-ID.
Tenant en organisatie.
Actietype.
Module, tabel en record-ID.
Resultaat van de actie.
Reden of autorisatiegrond.
Technische context.
Risiconiveau.
Oude en nieuwe waarde, waar verantwoord.
Auditlogs mogen zelf geen onnodige persoonsgegevens of wachtwoorden bevatten. Ze moeten tegen wijziging worden beschermd en alleen toegankelijk zijn voor bevoegde personen. Ook het bekijken en exporteren van auditlogs wordt gelogd.
Gebruikers moeten in het portaal kunnen zien:
Welke persoonsgegevens PadelOS verwerkt.
Voor welke doeleinden dit gebeurt.
Welke organisatie verantwoordelijk is.
Welke verwerkers betrokken zijn.
Hoelang gegevens worden bewaard.
Welke rechten de gebruiker heeft.
Welke toestemmingen zijn gegeven.
Hoe toestemming kan worden ingetrokken.
Waar een privacyverzoek kan worden ingediend.
Toestemming mag niet als standaardgrondslag voor iedere verwerking worden gebruikt. Afhankelijk van de situatie kan verwerking gebaseerd zijn op:
Uitvoering van een overeenkomst.
Wettelijke verplichting.
Gerechtvaardigd belang.
Vitaal belang.
Publieke taak.
Vrije, specifieke, geïnformeerde en aantoonbare toestemming.
Marketing, openbare profielen, het delen van beeldmateriaal en bepaalde externe communicaties vereisen mogelijk een afzonderlijke keuze. Het weigeren van optionele toestemming mag de noodzakelijke dienstverlening niet blokkeren.
De toestemmingsregistratie bevat minimaal het doel, de versie van de informatie, datum, status, wijze van verkrijgen en datum van intrekking.
PadelOS ondersteunt de belangrijkste AVG-verplichtingen:
Rechtmatige, behoorlijke en transparante verwerking.
Doelbinding.
Dataminimalisatie.
Juistheid.
Opslagbeperking.
Integriteit en vertrouwelijkheid.
Aantoonbare verantwoordelijkheid.
Gebruikers moeten verzoeken kunnen indienen voor:
Inzage.
Correctie.
Verwijdering.
Beperking van verwerking.
Overdraagbaarheid.
Bezwaar.
Intrekking van toestemming.
Beoordeling van geautomatiseerde besluitvorming.
Niet ieder verwijderverzoek betekent dat alle gegevens onmiddellijk mogen verdwijnen. Wettelijke administratieplichten, openstaande overeenkomsten, juridische claims en noodzakelijke beveiligingslogs kunnen een bewaarplicht rechtvaardigen. PadelOS moet daarom onderscheid maken tussen:
Actieve gegevens.
Geblokkeerde gegevens.
Gearchiveerde gegevens.
Geanonimiseerde gegevens.
Juridisch verplicht bewaarde gegevens.
Definitief verwijderde gegevens.
Per tabel en gegevenstype moeten bewaartermijnen worden vastgesteld. Na afloop volgt verwijdering of anonimisering volgens een controleerbaar beleid.
Het PadelOS-portaal communiceert via beveiligde API-aanvragen met de database en Registry. Iedere aanvraag moet server-side worden gecontroleerd.
Een beveiligde API controleert:
De identiteit van de gebruiker.
De geldigheid van de sessie of het token.
De tenant en organisatie.
De rol en concrete bevoegdheid.
De toegestane velden.
De geldigheid van invoer.
De omvang en frequentie van aanvragen.
Het risico van de handeling.
De herkomst en integriteit van het verzoek.
Aanvullende maatregelen zijn:
HTTPS voor alle communicatie.
Gestructureerde validatie van invoer.
Output-encoding tegen scriptinjectie.
Bescherming tegen CSRF, XSS en injectieaanvallen.
Rate limiting.
Gepagineerde gegevensopvraging.
Geen gevoelige informatie in foutmeldingen.
Versiebeheer van API’s.
Beperkte API-scopes.
Intrekbare toegangstokens.
Versleutelde webhookgeheimen.
Logging en monitoring van integraties.
Koppelingen met agenda’s, betalingen, e-mail, boekhouding of andere platforms krijgen uitsluitend toegang tot de gegevens die voor de koppeling noodzakelijk zijn.
De eerste versie van PadelOS gebruikt Google Apps Script, Google Sheets en een HTML-portaal. Deze techniek maakt snelle ontwikkeling en gecontroleerde pilots mogelijk, maar kent beperkingen.
Tabellen en velden centraal registreren.
Gebruikers aan personen en profielen koppelen.
Rollen in tabellen vastleggen.
Frontendonderdelen per rol tonen of verbergen.
CRUD-handelingen via Apps Script uitvoeren.
Organisatie-ID’s aan records toevoegen.
Basisvalidatie toepassen.
Wijzigingen en fouten loggen.
Google-accountidentiteit gebruiken.
Toegang tot spreadsheets beperken.
Tijdens pilots moeten minimaal de volgende afspraken gelden:
Geen echte wachtwoorden in Sheets opslaan.
Alleen noodzakelijke persoonsgegevens gebruiken.
Pilotaccounts handmatig controleren.
De spreadsheet niet openbaar delen.
Apps Script niet anoniem publiceren wanneer persoonsgegevens bereikbaar zijn.
Elke backendfunctie rechten laten controleren.
Testgegevens en productiegegevens scheiden.
Exports beperken en registreren.
Regelmatig back-ups maken.
Toegang direct intrekken bij vertrek.
Geen medische of andere bijzondere persoonsgegevens verwerken zonder afzonderlijke beoordeling.
Duidelijk aangeven dat het om een pilotomgeving gaat.
Google Sheets mag niet als volwaardig beveiligingsmechanisme worden beschouwd. Rollen die alleen in de interface worden verborgen, bieden onvoldoende bescherming. De backend moet de toegang afdwingen.
Voor verdere professionalisering groeit PadelOS door naar CAMTESI: Cloud Architecture & Multi-Tenant Engine – System International. Binnen deze architectuur krijgt iedere organisatie een logisch geïsoleerde omgeving.
Benodigde onderdelen zijn:
Centrale identity provider.
Multi-factor-authenticatie.
Tenant- en organisatiebeheer.
Centrale autorisatieservice.
Relationele database met tenantisolatie.
Versleuteling tijdens transport en opslag.
Secrets management.
Veilige objectopslag voor documenten.
API-gateway.
Rate limiting en bescherming tegen misbruik.
Centrale auditlogging.
Monitoring en waarschuwingen.
Back-ups en gecontroleerde hersteltests.
Gescheiden ontwikkel-, test-, acceptatie- en productieomgevingen.
Geautomatiseerde beveiligingstests.
Kwetsbaarhedenbeheer.
Incidentrespons.
Beschikbaarheids- en continuïteitsmaatregelen.
Verwerkers- en leveranciersbeheer.
Tenantisolatie moet in meerdere lagen worden afgedwongen:
Het account hoort bij een geldige tenant.
Het sessietoken bevat een gecontroleerde tenantcontext.
De API valideert de tenant.
Iedere query wordt op tenant-ID beperkt.
Opslag en exports volgen dezelfde scheiding.
Auditlogs registreren de tenantcontext.
Geautomatiseerde tests proberen toegang tussen tenants te voorkomen.
Voor grotere of gevoeligere organisaties kan aanvullende fysieke datascheiding worden aangeboden.
Belangrijke risico’s voor PadelOS zijn:
Onjuiste roltoekenning.
Misbruik van een Administrator-account.
Gelekte exports of spreadsheets.
Onbedoelde toegang tussen organisaties.
Verouderde accounts.
Phishing en gestolen sessies.
Onveilige API-koppelingen.
Fouten bij bulkimport.
Onherstelbare verwijderingen.
Onvoldoende logging.
Onjuiste verwerking van minderjarigen.
Te ruime toegang voor trainers of vrijwilligers.
Beschikbaarheid van de gebruikte cloudomgeving.
Menselijke fouten bij configuratie.
PadelOS ontwikkelt daarvoor procedures voor:
Accountblokkering.
Intrekking van sessies en tokens.
Isolatie van een getroffen tenant.
Herstel van records en configuraties.
Controle van auditlogs.
Technisch en organisatorisch onderzoek.
Documentatie van het incident.
Informeren van verantwoordelijken.
Beoordeling van meldplichtige datalekken.
Communicatie met betrokkenen.
Herstel uit back-ups.
Evaluatie en structurele verbetering.
Back-ups zijn pas betrouwbaar wanneer herstel regelmatig wordt getest. PadelOS moet daarom hersteldoelen vastleggen voor zowel de maximale hersteltijd als het maximaal aanvaardbare gegevensverlies.
Informatiebeveiliging is een gedeelde verantwoordelijkheid.
PadelOS-platformbeheer
Ontwikkelt en onderhoudt de technische beveiligingsmaatregelen.
Beheert platformrisico’s, kwetsbaarheden en incidentprocedures.
Levert documentatie en beheermogelijkheden.
Maakt duidelijk welke partijen gegevens verwerken.
Clubs, padelscholen en organisaties
Bepalen voor welke doelen persoonsgegevens worden gebruikt.
Kennen rollen zorgvuldig toe.
Houden accounts actueel.
Informeren gebruikers.
Stellen bewaartermijnen en werkafspraken vast.
Beoordelen welke medewerkers toegang nodig hebben.
Administrators en managers
Gebruiken geen gedeelde accounts.
Controleren uitnodigingen en rolwijzigingen.
Melden fouten en incidenten.
Beperken exports.
Trekken toegang tijdig in.
Trainers, spelers en viewers
Beschermen hun account.
Delen geen inlogmiddelen.
Melden verdachte activiteiten.
Gebruiken persoonsgegevens uitsluitend voor het toegestane doel.
Fase 1 – Basisbeveiliging
Centrale tabellen voor gebruikers, personen en profielen.
Vaste rollen.
Actieve en geblokkeerde accountstatus.
Backendcontrole op CRUD-handelingen.
Basislogging.
Fase 2 – Organisatiegebonden toegang
Tenant- en organisatie-ID’s.
Trainer-spelerrelaties.
Rechten per module en tabel.
Beperkte imports en exports.
Accountuitnodigingen.
Fase 3 – Professionele authenticatie
Externe identity provider.
Multi-factor-authenticatie.
Veilige sessies.
Wachtwoordherstel en apparaatbeheer.
Risicogebaseerde toegangscontrole.
Fase 4 – Privacy en governance
Toestemmingsregister.
Bewaartermijnen.
AVG-verzoeken.
Verwerkingsregister.
Verwerkersafspraken.
Privacy- en beveiligingsbeleid.
Fase 5 – CAMTESI multi-tenant cloudplatform
Sterke tenantisolatie.
Centrale autorisatieservice.
Versleutelde database en opslag.
API-gateway.
Monitoring en incidentdetectie.
Geteste back-up- en herstelarchitectuur.
Fase 6 – Assurance en schaalvergroting
Onafhankelijke beveiligingstests.
Periodieke toegangsreviews.
Leveranciersbeoordelingen.
Continuïteits- en incidentoefeningen.
Formele compliance- en certificeringstrajecten waar passend.
PadelOS nodigt securityspecialisten, privacydeskundigen, ontwikkelaars, clubs, padelscholen, pilotgebruikers en technologiepartners uit om mee te werken aan een platform dat niet alleen gebruiksvriendelijk is, maar ook aantoonbaar veilig, transparant en verantwoord kan groeien.
De ontwikkeling begint gecontroleerd in Google Apps Script en Google Sheets, maar de beveiligingsprincipes zijn vanaf het begin gericht op een professioneel internationaal multi-tenant platform. Zo groeit PadelOS uit tot één betrouwbare digitale werkruimte voor de volledige padelorganisatie.