Tietoturvan vaatimustenmukaisuus: suojaa tiedon koko elinkaari

Tietoturvaa on helpompi arvioida, kun tiimi pystyy seuraamaan tietoa keräämisestä poistamiseen. Asiaankuuluvat kontrollit riippuvat arkaluonteisuudesta, käyttötarkoituksesta, käyttäjistä sekä tiedon menetyksen tai väärinkäytön seurauksista. Tuotantotietokanta voi olla hyvin suojattu, vaikka samat tiedot ovat edelleen alttiina vietyissä taulukoissa, tukipyyntöjen liitteissä, analytiikkaputkissa tai varmuuskopioissa.

Teknologiajohtajalle tietoturvan vaatimustenmukaisuus on siksi tekninen ja näyttöön liittyvä ongelma: selvitetään, mitkä vaatimukset ovat sovellettavia, muunnetaan ne kontrolleiksi jokaisessa tietovirrassa ja osoitetaan, että kontrollit toimivat. Politiikat kuvaavat tavoiteltua toimintaa. Konfiguraatiot, testit, lokit ja katselmoidut poikkeukset osoittavat, toimiiko järjestelmä todella niin.

Erottakaa tietoturvavaatimukset laajemmista tietoihin liittyvistä velvoitteista

Tietoturvan vaatimustenmukaisuus koskee suojaamista luvattomalta pääsyltä, paljastumiselta, muuttamiselta, tuhoamiselta ja saatavuuden menettämiseltä. Se kattaa henkilötiedot mutta myös lähdekoodin, taloustiedot, immateriaalioikeudet, tunnistetiedot ja muut arkaluonteiset liiketoimintatiedot.

Laajempi tietojen vaatimustenmukaisuus sisältää kysymyksiä, joihin tietoturvakontrollit eivät yksinään pysty vastaamaan: onko kerääminen lainmukaista, mitkä käyttötarkoitukset ovat sallittuja, mitä ilmoituksia tai sopimuksia tarvitaan, miten yksilöt käyttävät oikeuksiaan ja kuinka kauan tietoja saa säilyttää. Salaus ei tee perusteettomasta keräämisestä lainmukaista. Pätevä käsittelyn tarkoitus ei tee turvattomasta toteutuksesta hyväksyttävää.

Pitäkää kolme vaatimusten lähdettä erillään:

• Lainsäädäntö ja sääntely: velvoitteet, jotka määräytyvät lainkäyttöalueen, käsittelytoimien, organisaation roolin ja toimialan mukaan.
• Standardit ja varmennusviitekehykset: jäsennellyt lähestymistavat tietoturvan hallintaan tai riippumattomaan arviointiin.
• Sopimukset ja sisäiset sitoumukset: asiakasehdot, toimittajasopimukset, käsittelyä koskevat politiikat ja palvelulupaukset.

Kirjatkaa jokaisen vaatimuksen lähde, soveltamisala, vastuullinen omistaja ja tulkinta. Kehitys voi sen jälkeen toteuttaa yhteiset suojaukset käsittelemättä virheellisesti jokaista viitekehystä oikeudellisesti samanarvoisena.

Selvittäkää sovellettavuus ennen kontrollien valintaa

Hyödyllinen sovellettavuusrekisteri selittää, miksi vaatimus on sovellettava, eikä vain sitä, että joku on lisännyt sen tarkistuslistaan.

Nämä ovat lähtökysymyksiä, eivät täydellisiä oikeudellisia testejä. Esimerkiksi terveyteen liittyvä ohjelmisto ei automaattisesti kuulu HIPAA:n piiriin pelkästään siksi, että se käsittelee terveystietoja. Maksujen käsittelyn ulkoistaminen voi kaventaa PCI DSS:n soveltamisalaa, mutta se ei automaattisesti poista kauppiaan vastuita.

GDPR:n 32 artikla edellyttää riskiä vastaavaa turvallisuustasoa ottaen huomioon muun muassa käsittelyn luonteen, toteuttamiskustannukset ja uusimman tekniikan. Se mainitsee toimenpiteitä kuten salauksen, häiriönsietokyvyn, palauttamisen ja säännöllisen arvioinnin; se ei aseta yleistä, kaikkea koskevaa salausvelvoitetta.

ISO 27001 koskee rajattua tietoturvan hallintajärjestelmää. Sen vaatimuksiin kuuluvat riskien käsittely, sisäinen auditointi ja johdon katselmus. Liitteen A kontrolleja tarkastellaan riskiperusteisen sovellettavuuden kautta, ja päätökset dokumentoidaan soveltuvuuslausumaan. Sertifioinnin suorittaa riippumaton sertifiointielin.

SOC 2 on varmennusraportti, ei sertifiointi. Sen kriteerit koskevat tietoturvaa sekä, jos ne sisältyvät soveltamisalaan, saatavuutta, käsittelyn eheyttä, luottamuksellisuutta ja yksityisyyttä. Sen enempää SOC 2 -raportti kuin ISO-sertifikaattikaan ei osoita GDPR:n noudattamista.

Toimialakohtaiset velvoitteet edellyttävät omaa arviointiaan. SOX koskee asianomaisten yritysten taloudellista raportointia ja siihen liittyviä sisäisiä kontrolleja; CMMC koskee määriteltyjä puolustushankintasopimusten vaatimuksia ja tietoympäristöjä. Euroopassa NIS2 edellyttää toimialan, koon, palvelun ja soveltamissääntöjen analyysia kansallisen täytäntöönpanon mukaisesti. DORA kattaa ensisijaisesti määritellyt finanssialan yhteisöt, ja siihen sisältyy sopimusvelvoitteita tieto- ja viestintäteknologian palveluntarjoajille sekä valvontajärjestelmä nimetyille kriittisille palveluntarjoajille. Älkää olettako, että jokaisella fintech- tai teknologiatoimittajalla on samat suorat velvoitteet.

Rakentakaa elinkaarikartta, joka sisältää myös toissijaiset kopiot

Aloittakaa yhdestä tärkeästä liiketoimintaprosessista, kuten potilaiden rekisteröinnistä, palkanlaskennasta, asiakastuesta tai maksujen täsmäytyksestä. Tunnistakaa sen tiedon omistaja ja tekninen omistaja ja seuratkaa sitten tietoa keräämisen, käytön, jakamisen, tallentamisen, palauttamisen ja hävittämisen läpi.

Kirjatkaa jokaisesta tietojoukosta:

• Sen käyttötarkoitus, arkaluonteisuus ja sovellettavat käsittelyvaatimukset.
• Lähdejärjestelmät, tallennuspaikat, rajapinnat ja vastaanottajat.
• Ihmiskäyttäjät, palvelutilit, toimittajat ja etuoikeutetut pääsypolut.
• Johdetut tietojoukot, viennit, välimuistit, testikopiot, lokit ja varmuuskopiot.
• Säilytysajan käynnistäjät, poistotavat ja poikkeukset.

Luokittelun tulee johtaa päätöksiin. Merkintä kuten ”rajoitettu terveystieto” on hyödyllinen vain, jos se määrää sallitut kohteet, käyttöoikeussäännöt, lokituksen, salauksen ja hävittämisen. Yhdistäkää luottamuksellisuus eheyteen ja saatavuuteen: muutettu lääkemääräys tai saavuttamattomissa oleva potilastieto voi aiheuttaa vahinkoa ilman paljastumistakin.

Validoikaa kartta arkkitehtuurikaavioita, tietokantaskeemoja, integraatioasetuksia, tallennusinventaarioita sekä asiakastuen ja operoinnin henkilöstön haastatteluja vasten. Tunnistustyökalut voivat löytää ehdokkaita, mutta omistajan on vahvistettava käyttötarkoitus ja käsittely. Jatkakaa tietojen tunnistamiseen, jos tiimi ei vielä pysty selittämään, missä arkaluonteiset tiedot sijaitsevat.

Toteuttakaa suojaukset elinkaaren jokaisessa vaiheessa

Kerääminen: minimoikaa tiedot ja rajatkaa vastaanotto

Kerätkää vain se, mitä hyväksytty käyttötarkoitus edellyttää. Poistakaa tarpeettomat lomakekentät ja välttäkää rajoittamattomien liitteiden vastaanottamista, kun jäsennelty syöte riittää. Validoikaa hyötykuorman koko, tyyppi ja sisältö; suojatkaa vastaanottorajapinnat luvattomilta lähetyksiltä ja väärinkäytöltä.

Yhdistäkää henkilötietojen osalta keräysrajapinta dokumentoituun käsittelyn tarkoitukseen ja sovellettavaan oikeusperusteeseen. GDPR:ssä suostumus on yksi mahdollinen 6 artiklan mukainen peruste, ei yleinen edellytys. Kun suostumusta käytetään, sovelluksen on tuettava asianmukaista suostumuksen elinkaarta eikä vain näytettävä valintaruutua.

Pitäkää salaisuudet ja arkaluonteiset hyötykuormat poissa URL-osoitteista, virheilmoituksista ja sovelluksen telemetriasta. Testatkaa virhepolut: hylätyn lähetyksen ei pidä jättää täydellistä kopiota virheenjäljityspalveluun.

Käyttö ja pääsy: pankaa valtuutus täytäntöön lähellä tietoja

Tunnistautuminen vahvistaa identiteetin; valtuutus määrää, mihin tietoihin ja toimintoihin tällä identiteetillä on pääsy. Toteuttakaa molemmat. Kirjautunut käyttäjä ei saa päästä toisen asiakkaan tietoihin vaihtamalla tunnistetta.

Käyttäkää vähimpien oikeuksien periaatetta, erottakaa hallinnolliset tehtävät tarvittaessa toisistaan ja edellyttäkää vahvempaa tunnistautumista arkaluonteiseen tai etuoikeutettuun pääsyyn. Antakaa palvelutileille tiukasti rajatut oikeudet sen sijaan, että käyttäisitte uudelleen ihmisten tunnistetietoja. Varmistakaa, että aloittavien, siirtyvien ja lähtevien työntekijöiden prosessit kattavat sovellusroolit, pilvioikeudet, API-tunnisteet ja toimittajien pääsyn.

Määritelkää tukihenkilöstön pääsylle hyväksyntäehdot, aikarajat, sallitut toiminnot ja kirjausketjut. Katselmoikaa pääsy nykyistä liiketoimintatarvetta vasten eikä vain sen perusteella, onko tili edelleen aktiivinen. Näyttöön tulee sisältyä valtuutustestejä, käyttöoikeuskatselmointien päätöksiä ja esimerkkejä poistetuista oikeuksista.

Tuotantodata ei saa muodostua oletusarvoiseksi testiaineistoksi. Suosikaa synteettistä dataa. Jos poikkeus oikean datan käyttämiseksi on perusteltu, hyväksykää sen laajuus, rajoittakaa pääsyä ja asettakaa päättymispäivä. Pseudonymisointi voi vähentää altistusta, mutta pseudonymisoidut henkilötiedot kuuluvat edelleen GDPR:n piiriin, jos yksilöt voidaan tunnistaa uudelleen lisätietojen avulla.

Tallennus ja siirto: suojatkaa tiedot ja niiden avaimet

Erottakaa tallennetun tiedon salaus siirrettävän tiedon salauksesta. Tallennuksen salaus suojaa tietyiltä menetys- tai pääsyskenaarioilta; siirtosalaus suojaa tietoliikennekanavia. Kumpikaan ei estä valtuutettua sovellusta palauttamasta tietoja väärälle käyttäjälle.

Käyttäkää vakiintuneita, ylläpidettyjä kryptografisia toteutuksia ja nykyaikaista todennettua salausta. Määrittäkää tuetut siirtoprotokollat, validoikaa varmenteet ja poistakaa vanhentuneet konfiguraatiot. Välttäkää omien kryptografisten ratkaisujen suunnittelua.

Avaintenhallinta on osa kontrollia, ei toteutuksen alaviite. Dokumentoikaa, kuka voi käyttää, hallinnoida, kierrättää, mitätöidä ja palauttaa avaimia. KMS tukee hallittuja avainoperaatioita; HSM voi tarjota kryptografiselle materiaalille laitteistopohjaisen suojauksen. Valitkaa lähestymistapa uhkamallin ja toiminnallisten vaatimusten mukaan.

Erottakaa avainten hallinnointi rutiininomaisesta tietojen käytöstä aina kun mahdollista. Testatkaa, että mitätöity pääsy todella estää salauksen purkamisen ja että palautuminen on edelleen mahdollista oikeutetun infrastruktuurivian jälkeen. Ainoan käyttökelpoisen avaimen menettäminen voi tehdä ehjistä varmuuskopioista käyttökelvottomia. Katsokaa toiminnalliset erot artikkelista salaus ja avaintenhallinta.

Siirrot tarvitsevat myös vastaanottajaa koskevia kontrolleja. Käyttäkää hyväksyttyjä kohteita, rajattuja API-tunnistetietoja ja tarvittaessa aikarajoitettuja latausoikeuksia. Seuratkaa vientejä kopioina, joilla on omistajat ja päättymissäännöt, eikä tapahtumina, joihin vastuu päättyy.

Eheys ja saatavuus: testatkaa toiminnalliset väitteet

Suojatkaa eheyttä syötteiden validoinnilla, tietokantarajoitteilla, hallituilla muutoksilla, täsmäytyksellä ja tietoihin soveltuvilla kirjausketjuilla. Tarkistussumma voi havaita joitakin muutoksia; se ei osoita, kenellä oli valtuudet tehdä ne.

Määritelkää palautumistavoitteet liiketoiminnallisten seurausten perusteella. Valitkaa varmuuskopioinnin tiheys ja palautuksen rakenne niiden mukaisesti. Suojatkaa varmuuskopiot vahingossa tapahtuvalta poistolta ja vaarantuneilta ylläpitäjiltä ja rajoittakaa pääsyä niihin tavallisesta sovelluspääsystä riippumatta aina kun mahdollista.

Palautumisväitteen tulee liittyä testiin eikä pelkkään varmuuskopiointikonfiguraatioon. Palauttakaa eristettyyn ympäristöön, todentakaa tietojen täydellisyys ja johdonmukaisuus, tarkistakaa sovelluksen riippuvuudet ja mitatkaa todellinen palautumissuorituskyky. Kirjatkaa epäonnistumiset ja korjaava työ. Onnistunut tietokannan palautus ei riitä, jos tarvittavat avaimet, tiedostot tai identiteettipalvelut puuttuvat.

Säilytys ja hävittäminen: tehkää poistamisesta toteutettavaa

Määritelkää säilytysaika tietoluokan ja käyttötarkoituksen mukaan selkeällä käynnistäjällä: tilin sulkeminen, sopimuksen päättyminen, tallennetapahtuma tai muu perusteltu ehto. Yhdistäkää politiikka toteutettuihin sääntöihin tietokannoissa, objektivarastoissa, hakuindekseissä, analytiikkajärjestelmissä ja toimittajien palveluissa.

Poistaminen tarvitsee uudelleenyritysten käsittelyn ja täsmäytyksen. Tehtävä, joka raportoi onnistumisen mutta ohittaa epäonnistuneen jatkopyynnön, ei todista hävittämistä. Ylläpitäkää katselmoituja poikkeuksia oikeudellisia säilytysvelvoitteita tai muuta perusteltua säilyttämistä varten, mukaan lukien omistajuus ja päättymisehto.

Varmuuskopiot edellyttävät dokumentoitua mallia. Selittäkää vanhenemisajat, tavallista käyttöä koskevat rajoitukset ja se, miten aiemmin poistettuja tietoja käsitellään, jos varmuuskopio palautetaan. Älkää luvatko välitöntä poistamista kaikkialta, jos arkkitehtuuri ei pysty siihen. Turvallinen hävittäminen kattaa myös viedyt tiedostot, käytöstä poistetut laitteet ja toimittajasuhteiden päättämisen.

Käsitelkää pilvipalvelujen varmuutta rajattuna näyttönä

Pilvipalvelut jakavat vastuut uudelleen; ne eivät poista niitä. Tunnistakaa, mitä palveluntarjoaja operoi ja mitä tiiminne konfiguroi, mukaan lukien identiteetit, verkkoaltistus, salausasetukset, sovelluksen valtuutus, lokitus, säilytys ja palautuminen.

Arvioikaa toimittajan varmuus todellisen palvelun osalta. Tarkistakaa raportin soveltamisala, arviointijakso, poissulkemiset, asiakkaan vastuut ja ratkaisemattomat havainnot. Palveluntarjoajan sertifikaatti ei todista, että tallennussäiliönne, sovelluksenne tai ylläpitäjien oikeudet on konfiguroitu oikein.

Sijainti on toinen rajattu kysymys. Kartoittakaa ensisijainen tallennus, replikat, katastrofipalautus, tukihenkilöstön pääsy, alihankkijat ja telemetrian kohteet. Hosting valitulla alueella ei yksinään osoita datasuvereniteettia tai GDPR:n noudattamista. Kansainvälisten siirtojen arvioinnit ovat erillisiä GDPR:n 28 artiklan käsittelijäsopimuksia koskevista vaatimuksista.

Määritelkää ennen käyttöönottoa sopimukselliset odotukset poikkeamille, pääsylle, alihankkijoille, tietojen palauttamiselle, poistamiselle ja palvelusta irtautumiselle. Testatkaa, ovatko viedyt tiedot käyttökelpoisia ja onko toimittajalta saatavissa näyttöä poistamisesta. Toimittaja, joka ei pysty tukemaan vaatimaanne elinkaarta, luo arkkitehtuuripäätöksen eikä pelkkää hankintamerkintää.

Soveltakaa terveysteknologian kontekstia sulauttamatta erillisiä velvoitteita yhteen

Terveysteknologia havainnollistaa, miksi tietojen konteksti on tärkeä. Terveystiedot kuuluvat GDPR:n 9 artiklan mukaisiin erityisiin henkilötietoryhmiin, ja lisäksi tarvitaan 6 artiklan mukainen oikeusperuste. Dokumentoikaa asiaankuuluva 9 artiklan ehto sen sijaan, että olettaisitte jokaisen terveystietoja koskevan toiminnon voivan nojata samaan perusteeseen.

Arvioikaa, aiheuttaako käsittely todennäköisesti korkean riskin ja edellyttääkö se siksi 35 artiklan mukaista tietosuojaa koskevaa vaikutustenarviointia. Tietoturvanäytön tulee heijastaa todennäköistä vahinkoa: virheelliset tiedot, henkilöstön asiaton pääsy, paljastuminen ilmoitusten kautta ja palvelujen saavuttamattomuus voivat kaikki olla merkityksellisiä.

Lääkinnällisiä laitteita koskevat velvoitteet riippuvat tuotteesta ja sen käyttötarkoituksesta. MDR- tai IVDR-arviointi on erillinen kokonaisuus tietosuojasta ja tietoturvasta. Sähköisten potilastietojärjestelmien tuotteet ja toissijainen käyttö edellyttävät myös arviointia eurooppalaista terveysdata-avaruutta koskevien sovellettavien säännösten ja vaiheittain voimaan tulevien vaatimusten valossa. Kansalliset terveydenhuolto- ja korvaussäännöt voivat tuoda lisärajoitteita.

Myynti sairaalalle ei automaattisesti määritä jokaisen toimittajan suoraa NIS2-asemaa. Dokumentoikaa oikeudellinen sovellettavuus erillään sairaalan sopimuksellisista tietoturvavaatimuksista. Asiakkaiden pyynnöt ISO-sertifioinnista, SOC 2:sta tai muusta varmuudesta voivat olla kaupallisesti tärkeitä olematta yleisiä lakisääteisiä vaatimuksia.

Rakentakaa näyttö väitteiden ympärille ja valvokaa poikkeamia mallista

Määritelkää jokaiselle olennaiselle kontrollille väite, toteutuksen omistaja, soveltamisala, näytön lähde, testi, katselmoija ja katselmoinnin käynnistäjä. Pitäkää politiikkaa, konfiguraatiota ja vaikuttavuutta koskeva näyttö erillään.

Käyttäkää näyttöä uudelleen silloin, kun se tukee useita vaatimuksia, mutta säilyttäkää kunkin vaatimuksen tulkinta. Kontrollien kohdistus on monen suhde moneen; yhteinen käyttöoikeuskatselmointi ei osoita jokaisen lakisääteisen velvoitteen täyttymistä.

Valvokaa muutoksia, jotka voivat tehdä mallista pätemättömän: uusia integraatioita, oikeuksien muutoksia, käytöstä poistettua kirjausketjun lokitusta, epäonnistuneita varmuuskopioita, poistovirheitä ja uusia kohteita. Ohjatkaa hälytykset omistajille eskalointipolun kanssa. Määräaikaisissa auditoinneissa tulee tarkistaa otannalla, toimivatko nämä tarkistukset, eikä vain sitä, onko kojelauta olemassa. Tunkeutumistestaus voi olla perusteltua riskin tai sopimusvaatimusten vuoksi, mutta se ei ole ISO 27001:n tai SOC 2:n mukainen yleinen pakollinen testi.

Sisällyttäkää näyttösuunnitelmaan poikkeamien käsittely. GDPR:n mukaan henkilötietojen käsittelijät ilmoittavat rekisterinpitäjille ilman aiheetonta viivytystä. Rekisterinpitäjät arvioivat valvontaviranomaiselle ilmoittamisen ilman aiheetonta viivytystä ja mahdollisuuksien mukaan 72 tunnin kuluessa siitä, kun tietoturvaloukkaus on tullut niiden tietoon, paitsi jos loukkauksesta ei todennäköisesti aiheudu riskiä luonnollisten henkilöiden oikeuksille ja vapauksille. Korkean riskin loukkaukset voivat edellyttää myös tiedottamista rekisteröidyille 34 artiklan poikkeusten mukaisesti. Kirjatkaa perustelut ilmoittamatta jättämiselle ja arvioikaa muut sopimukselliset tai toimialakohtaiset raportointivelvoitteet erikseen.

Esimerkki: tukiviennin aukon sulkeminen

Oletetaan havainnollistavasti, että terveysteknologian SaaS-palveluntarjoaja käsittelee klinikoiden ajanvaraus- ja oiretietoja. Sen ensisijainen tietokanta on salattu, sovelluspääsy on rajattu asiakaskohtaisesti ja varmuuskopiot ovat olemassa. Elinkaarikatselmoinnissa havaitaan, että tukihenkilöstö vie tietoja taulukoihin ja liittää ne tukipyyntöihin.

Vienti luo kaksi lisätallennuspaikkaa: paikalliset laitteet ja tukipyyntöjärjestelmän toimittajan. Tietokannan kontrollit eivät automaattisesti suojaa kumpaakaan. Tiimi varmistaa ensin, tarvitaanko täydellisiä tietoja tukiongelman diagnosoimiseksi, onko kohde hyväksytty ja mitä sopimuksellisia rajoituksia sovelletaan.

Sen jälkeen se korvaa rutiininomaiset viennit peitetyillä diagnostiikkanäkymillä. Poikkeukselliset viennit edellyttävät hyväksyntää, rajattua kohdetta, rajattuja kenttiä ja päättymispäivää. Toimittajan pääsy- ja säilytysasetukset katselmoidaan; paikallisia latauksia rajoitetaan organisaation hyväksytyillä päätelaitekontrolleilla.

Näyttöpaketti sisältää päivitetyn tietovirtakartan, vientioikeuksien testit, katselmoidun poikkeuksen, toimittajan konfiguraationäytön ja poistojen tulokset. Kielteinen testi vahvistaa, että tavallinen tukirooli ei voi viedä toisen klinikan tietoja. Vanhenemistesti tarkistaa sekä sovelluksessa olevan kopion että tukipyynnön liitteen.

Jäljelle jäävä aukko on nimetty: historialliset liitteet on selvitettävä ja hävitettävä, kun se on perusteltua. Omistaja saa tämän tehtävän valmistumiskriteereineen. Tiimi ei väitä elinkaaren olevan vaatimusten mukainen pelkästään siksi, että uusi vientipainike on turvallisempi.

Tehkää ensin yhdestä arkaluonteisesta tietovirrasta katselmoitava

Aloittakaa rajatusta tietovirrasta ja tuottakaa viisi tuotosta: todennettu tietokartta, sovellettavuuspäätökset, kontrollien omistajat, testattu näyttö ja priorisoitu puuterekisteri. Käsitelkää altistukset ja palautumisen puutteet ennen dokumentaation kosmeettisia parannuksia. Antakaa poikkeuksille hyväksyjä, perustelut, korvaavat toimenpiteet ja katselmointipäivä.

Mallintakaa Secanissa sovellukset, järjestelmät, palvelut ja ulkoiset palveluntarjoajat, jotka tukevat tätä tietovirtaa. Yhdistäkää näyttö vaatimuksiin, kontrolleihin ja päätöksiin; osoittakaa puuttuva näyttö tai epäselvä omistajuus tehtäviksi. Tarkistakaa tekoälyavusteiset ehdotukset lähteitä vasten ja säilyttäkää ihmisten tekemät hyväksynnät ja aikaleimat. Näin omaisuuserät, vaatimukset, riskit ja näyttö pysyvät kontekstissaan ilman, että työkalu korvaa teknistä testausta tai oikeudellista analyysia.

Käytännön seuraava askel on yksi päästä päähän -katselmointi: valitkaa arkaluonteinen tietue, seuratkaa sen jokaista kopiota ja kysykää, mikä todistaa, että sen kerääminen, käyttö, palautus, säilytys ja poistaminen ovat hallinnassa.