Mitä tarkastajat todellisuudessa testaavat
Tiivistelmä
Monet tiimit käsittelevät 21 CFR Part 11:tä ohjelmiston ominaisuuksien tarkistuslistana. Tarkastajat harvoin lähestyvät sitä tällä tavalla. Käytännössä Part 11 testataan pienellä määrällä operatiivisia kysymyksiä: Kuka teki mitä? Milloin he tekivät sen? Mikä muuttui? Miksi se muuttui? Voidaanko tietueisiisi luottaa ilman narratiivista rekonstruktiota? Kun nämä vastaukset ovat epävarmoja, tarkastus laajenee nopeasti – koska tietueiden luotettavuus muuttuu epävarmaksi.
Tämä raportti tarjoaa käytännöllisen ja toimittajaneutraalin mallin siitä, miten tarkastajat arvioivat sähköisiä tallenteita ja sähköisiä allekirjoituksia todellisissa tiloissa. Se keskittyy tarkastajien yleisesti tutkimiin kontrollipintoihin: identiteetin ja pääsynhallintaan, tarkastuslokitietojen toimintaan, sähköisen allekirjoituksen merkitykseen ja sidontaan, hallittuihin muokkauksiin ja korjauksiin, tallenteiden säilytykseen ja hakuun, järjestelmän ajalliseen eheyteen sekä tietokonejärjestelmän validointia (CSV) tukevaan näyttöön . Raportissa tuodaan esiin myös usein unohdettuja mutta usein testattuja prosessuaalisia kontrolleja, kuten etuoikeutettujen käyttöoikeuksien hallintaa, säännöllistä käyttöoikeuksien tarkistusta, koulutusta/osaamista ja muutoshallintakuria.
Tavoitteena ei ole toistaa määräyksiä. Tavoitteena on kuvata, mitä pitää tehdä, kun tarkastajat pyytävät esittelyjä, näytön jakamista ja tallenteita paikan päällä. Artikkeli sisältää joukon "tarkastusharjoituksia", joita voit suorittaa sisäisesti mitataksesi, onko Part 11 -asenteesi puolustettava käytännössä, ei vain paperilla. Kun tiedon eheyden käsitteitä sovelletaan, artikkelissa viitataan tiedon eheyteen ja periaatteisiin, kuten ALCOA+: aan, käytännön ankkureina asiakirjojen luottamukselle.
Vahva osan 11 mukainen asenne ei tarkoita täydellisyyttä. Kyse on johdonmukaisesta ja osoitettavissa olevasta tietueiden luomisen, muuttamisen, hyväksymisen ja säilyttämisen hallinnasta – jota tukee todistusaineisto, joka on nopeasti, paineen alla ja ilman improvisointia saatavilla.
- Osa 11:n soveltamisala: mitä oikeastaan on kyse
- Miten tarkastajat testaavat osan 11 käytännössä
- Henkilöllisyys ja käyttöoikeudet: kuka teki mitä
- Auditointipolut: todisteet siitä, mikä muuttui, milloin ja miksi
- Sähköiset allekirjoitukset: merkitys, tarkoitus ja sitovuus
- Korjaukset, uudelleentyöstö ja hallitut muokkaukset
- Aika, aikaleimat ja kellon eheys
- Tietueiden säilytys, haku ja vienti
- Validointinäyttö: miltä ”riittävä” näyttää
- Menettelytarkastusten tarkastajat odottavat edelleen
- Rajapinnat ja integraatiot: rajapinnan vikaantumistilat
- Tarkastusharjoitukset: 10 testiä, jotka voit suorittaa sisäisesti
- Toteutussuunnitelma
- Päätös
Abstrakti
21 CFR Part 11 -standardia käytetään usein ominaisuuksien tarkistuslistana, mutta tarkastajat arvioivat sitä todistusjärjestelmänä: kykynä osoittaa luotettavia sähköisiä tietueita ja sähköisiä allekirjoituksia tarkastusolosuhteissa. Tässä artikkelissa ehdotetaan käytännöllistä tarkastuskeskeistä mallia, joka on järjestetty tarkastajien yleisesti tutkimien kontrollipintojen ympärille: identiteetin ja käyttöoikeuksien hallinta, tarkastuslokitietojen toiminta, allekirjoituksen merkitys ja sidonta, hallitut muokkaukset, aikaleiman eheys, säilytys ja haku sekä validointitodisteet. Mallia tukevat hallintoa ja muutosta koskevat proseduraaliset kontrollit, jotka ylläpitävät validoitua tilaa ajan kuluessa.
Artikkelissa esitetään myös tarkastusharjoituksia, joilla mitataan, pystyykö organisaatio tuottamaan puolustettavaa näyttöä nopeasti turvautumatta narratiiviseen rekonstruktioon. Hyvin toteutettuina nämä harjoitukset vähentävät tarkastusriskiä, nopeuttavat tutkimuksia ja parantavat tietojen eheyden tilaa.
1) Osa 11:n soveltamisala: mitä todellisuudessa on kyse
Osaa 11 sovelletaan, kun sähköisiä asiakirjoja tai sähköisiä allekirjoituksia käytetään predikaattisääntöjen edellyttämien paperiasiakirjojen tai käsin kirjoitettujen allekirjoitusten sijaan. Monet organisaatiot ylittävät osan 11 soveltamisalan käsittelemällä jokaista sähköistä artefaktia "osan 11 tietona". Toiset alittavat sen soveltamisalan olettamalla, että sääntö koskee vain "laatujärjestelmää". Tarkastajat keskittyvät tyypillisesti siihen, missä sähköiset asiakirjat tukevat säänneltyjä päätöksiä: julkaisu, hävittäminen, tutkimukset, muutokset ja hyväksynnät.
Käytännöllinen tapa määrittää laajuus on inventoida: (1) säänneltyjä päätöksiä tukevat tiedot, (2) kuka luo/muuttaa/hyväksyy ne, (3) mitkä järjestelmät tallentavat ne ja (4) mihin "totuuteen" organisaatio luottaa tarkastuksen ja tutkimuksen aikana. Tämän laajuusmäärityksen tulisi olla jäljitettävissä aiottuun käyttöön ja riskiin, mikä on yleisesti dokumentoitu CSV- tiedostossa.
Jos tilintarkastaja pyytäisi tätä rekisteriä huomenna, käsittelisitkö sähköistä versiota virallisena rekisterinä? Jos kyllä, osan 11 mukaiset kontrollit ja todistusaineistoon liittyvät odotukset kuuluvat todennäköisesti rekisterin soveltamisalaan.
2) Miten tarkastajat testaavat osan 11 vaatimuksia käytännössä
Tarkastajat arvioivat usein osan 11 vaatimuksia demonstraatioiden ja otantanäytteiden avulla. Kaava on johdonmukainen: he valitsevat tietueen (erätietue, poikkeama, muutos, laboratoriotulos, koulutus, kalibrointi, vapautuspäätös) ja jäljittävät sitten taaksepäin ja eteenpäin sen luojan, hyväksyjän, muutosten ja hallintaan liittyvien tietojen läpi. Tarkoituksena ei ole "onko järjestelmällä lokitietoa", vaan "tuottaako lokitieto luotettavaa historiaa tärkeille tietueille".
Alla olevassa taulukossa on yhteenveto tyypillisistä tarkastajien tekemistä tarkastuksista ja siitä, mitä organisaatioiden on kyettävä osoittamaan nopeasti.
| Tarkastajan luotain | Mitä he yleensä pyytävät nähdäkseen | Minkä täytyy olla totta |
|---|---|---|
| Kuka teki mitä? | Yksilölliset käyttäjätunnukset, roolitodisteet, käyttöoikeuksien myöntäminen ja tarkistustietueet. | Tilit ovat yksilöllisiä, hallittuja ja rooleihin sidottuja; etuoikeutettua käyttöoikeutta hallitaan. |
| Mitä muutettiin? | Keskeisten kenttien ja tapahtumien tarkastuslokimerkinnät, mukaan lukien muutoksen syy. | Auditointiketju on suojattu, täydellinen säännellyille kentille, eikä käyttäjät voi poistaa sitä käytöstä. |
| Milloin se tapahtui? | Aikaleimat ja aikalähteen toiminta; aikavyöhykkeen yhdenmukaisuus eri vientien välillä. | Kellon eheyttä hallitaan; aikaleimat ovat yhdenmukaisia ja ymmärrettäviä. |
| Onko allekirjoituksella merkitystä? | Allekirjoituksen merkitys, tarkoitus ja sidonta tietueen tilaan; allekirjoituksen muutoksen jälkeiset säännöt. | Allekirjoitukset edustavat tiettyjä toimia; allekirjoituksen jälkeiset muutokset ovat hallittuja ja näkyviä. |
| Voitko hakea tiedot nopeasti? | Tietueiden haku, säilytys, vienti ja täydellisyys kiireen paineessa. | Asiakirjat ovat saatavilla, täydellisiä ja kontekstisidonnaisia; säilytys on määritelty ja sitä valvotaan. |
| Onko se validoitu? | Käyttötarkoitus, riskinarviointi, protokollat, tulokset, poikkeamat, hyväksynnät, muutostenhallinta. | Validointinäyttö on jäljitettävissä ja keskittyy ohjauspintoihin ja säänneltyyn käyttöön. |
Tämän artikkelin loppuosa jakaa nämä kokeet käytännön ohjaimiin ja vikatiloihin painottaen sitä, mitä tarkastajat testaavat demonstraatioiden avulla, sen sijaan, mitä tiimit väittävät käytännöissään.
3) Henkilöllisyys ja käyttöoikeudet: kuka teki mitä
Osa 11 alkaa identiteetistä. Jos organisaatio ei pysty todistamaan, että toiminnot voidaan kohdistaa yksittäisiin henkilöihin, luottamus tietoihin romahtaa. Tarkastajat kysyvät usein, miten tilit luodaan, kuka hyväksyy käyttöoikeudet, miten roolit jaetaan, onko jaettuja tilejä olemassa ja miten käyttöoikeudet poistetaan, kun roolit vaihtuvat tai ihmiset lähtevät.
Identiteetti- ja käyttöoikeuksien hallinta toteutetaan usein käyttäjien käyttöoikeuksien hallinnan ja roolipohjaisen käyttöoikeuden avulla . Puolustavaan tilaan kuuluu dokumentoitu käyttöönotto, säännöllinen käyttöoikeuksien tarkistus ja etuoikeutettujen roolien hallinta. Myös istuntokohtaisia rajoituksia (aikakatkaisuja) testataan usein; katso tunnistetietojen aikakatkaisun hallinta.
- Yksilölliset tilit: ei jaettuja kirjautumisia säänneltyyn työhön.
- Vähiten oikeuksia käyttävät roolit: roolit vastaavat työtehtävien tarpeita; järjestelmänvalvojan oikeudet on minimoitu.
- Etuoikeutetun pääsyn hallinta: kuka voi ohittaa, muokata suojattuja kenttiä tai hallita tarkastusasetuksia.
- Käyttötarkistusten tahti: säännöllinen tarkastelu todisteineen ja korjaavine toimenpiteineen.
- Käyttöoikeuksien poistaminen: nopea poistaminen, kun ihmiset vaihtavat rooleja tai lähtevät.
4) Audit-lokit: todisteet siitä, mikä muuttui, milloin ja miksi
Auditointipolun toiminta on yksi yleisimmistä osan 11 eskalointikohdista. Tarkastajat pyytävät usein demonstraatioita: muokkaa kriittistä kenttää, näytä, miten järjestelmä tallentaa muutoksen, ja näytä sitten, miten kyseinen historia noudetaan myöhemmin. He saattavat myös kysyä, voidaanko auditointipolut poistaa käytöstä, suodattaa, korvata tai tyhjentää.
GxP:hen liittyvän tarkastusketjun tulisi olla suojattu, aikaleimattu, kohdennettu ja sisältää tarvittaessa sekä vanhat että uudet arvot. Sen tulisi myös tallentaa muutosten syy, kun suojattuihin kenttiin tehdään muutoksia. Katso tarkastusketju (GxP).
| Kysymys tarkastajilta | Mitä näyttää | Yleinen vikatila |
|---|---|---|
| Mitä kenttiä auditoidaan? | Suojattujen/säänneltyjen kenttien määritelmä ja tapahtumat, jotka käynnistävät auditoinnin. | Kirjausketju on olemassa, mutta siitä puuttuu avainkenttiä tai avaintapahtumia. |
| Voivatko käyttäjät muokata ilman jälkiä? | Esittele muokkaustoimintaa ja lokitietojen luomista. | Muokkauksia tehdään ilman muutostarvetta tai ilman vanhoja/uusia arvoja. |
| Voiko tarkastusketjua muuttaa? | Roolien hallinta ja tekniset hallintalaitteet, jotka estävät käytöstä poistamisen/puhdistuksen. | Ylläpitäjät voivat poistaa historian hiljaisesti; säilytysaika on epäselvä. |
| Miten tarkastetaan tarkastuslokeja? | Arviointimenettelyt ja todisteet säännöllisestä arvioinnista tarvittaessa. | Ei tarkastusprosessia; ongelmat löytyvät vain tarkastusten aikana. |
Auditointipolun uskottavuus on läheisesti sidoksissa tietojen eheyteen. Jos auditointipolun toimintaa ei voida selittää selkeästi, organisaatioiden tulisi olettaa, että tarkastajat tehostavat tietojen luotettavuuden käsitteiden tarkastelua tietojen eheyden ja ALCOA+:n mukaisesti.
5) Sähköiset allekirjoitukset: merkitys, tarkoitus ja sitovuus
Tarkastajat käsittelevät sähköisiä allekirjoituksia enemmän kuin "painikkeena". He testaavat, onko allekirjoituksilla merkitystä ja sitoutuvatko ne tietueen sisältöön allekirjoitushetkellä. He kysyvät usein, mitä allekirjoitus edustaa (tarkistus, hyväksyntä, varmennus, julkaisu), miten allekirjoittaja todennetaan ja mitä tapahtuu, jos tietue muuttuu allekirjoittamisen jälkeen.
Kun sähköisiä allekirjoituksia käytetään, organisaation tulisi pystyä osoittamaan: allekirjoituksen merkitys, allekirjoituksen ilmentymä tietueessa, todennusvaiheet ja allekirjoituksen yhteys allekirjoitettuun tietueversioon. Katso sähköiset allekirjoitukset.
- Merkitys: allekirjoitukset vastaavat määriteltyjä toimintoja (esim. ”laadunvarmistuksen käsittely”, ”tarkistus valmis”).
- Sidonta: Allekirjoitus on sidottu tietueen tilaan; allekirjoituksen jälkeinen muutos on hallittu ja näkyvä.
- Authentication: Allekirjoittaja tunnistetaan ja todennetaan yksilöllisesti käytäntöjen ja riskien mukaisesti.
- Näkyvyys: Allekirjoitetuista tiedoista käy ilmi, kuka allekirjoitti, milloin ja mitä toimenpiteitä tehtiin.
6) Korjaukset, uudelleentyöstö ja kontrolloidut muokkaukset
Todelliset toiminnot vaativat korjauksia. Tarkastajat eivät odota, ettei muutoksia tehdä. He odottavat muokkausten olevan läpinäkyviä, johtuvia ja hallittuja. Testinä on, säilyttävätkö korjaukset alkuperäiset merkinnät ja ovatko muutosten syyt ja hyväksynnät riskiin nähden riittäviä.
Yleisiä eskaloinnin laukaisevia tekijöitä ovat: hiljaiset päällekirjoitukset, säänneltyjen tietueiden poistaminen tai käyttöoikeutettujen käyttäjien tekemät muokkaukset ilman dokumentoitua perustetta. Hallittua muokkausta tulisi osoittaa sisäisissä harjoituksissa: valitse tietue, korjaa arvo, näytä lokitiedosto, näytä muutoksen syy, näytä tarkistus tai hyväksyntä tarvittaessa ja näytä, miten korjattu tietue noudetaan myöhemmin.
7) Aika, aikaleimat ja kellon eheys
Aikaleimojen eheyttä usein aliarvioidaan. Tarkastajat voivat kysyä, miten järjestelmän aikaa hallitaan, onko aika synkronoitu, miten aikavyöhykkeitä käsitellään ja mitä tapahtuu, jos kellot ajautuvat. He voivat myös vertailla aikaleimoja eri järjestelmien välillä, kun kyseessä on integraatioita.
Puolustavaan asenteeseen kuuluvat määritellyt aikalähteet, selkeät aikavyöhykkeiden näyttösäännöt ja todisteet siitä, että aikaleimojen toiminta on yhdenmukaista koko tietueen elinkaaren, viennin ja tarkastuspolkujen ajan. Jos aikaleimat ovat hämmentäviä tai epäjohdonmukaisia, tietueen rekonstruoinnista tulee narratiivi – eikä narratiivi ole todiste.
8) Tietueiden säilytys, haku ja vienti
Tarkastajat testaavat usein, voidaanko tiedot hakea nopeasti ja täydellisesti. ”Voimme hakea ne myöhemmin” ei ole vahva vastaus. Kun organisaatioiden on reagoitava nopeasti (joskus tätä kuvataan tietyissä yhteyksissä 24 tunnin vastausodotuksena ), hakukyvystä tulee käytännöllinen kontrolli.
Säilytys tulee määritellä ja valvoa. Haun tulee säilyttää konteksti: kuka, mitä, milloin, hyväksynnät, tarkastushistoria ja kaikki linkitetyt tietueet. Arkistointi- ja säilytysodotuksia käsitellään usein asiakirjojen säilytyksen/arkistoinnin yhteydessä . Vientien ei tulisi viedä merkitystä; tarkastushistorian menettänyt CSV-tiedosto ei ole sama kuin virallinen tietue.
9) Vahvistusnäyttö: miltä ”riittävä” näyttää
Tarkastajat kysyvät harvoin jokaista testiskriptiä. He pyytävät johdonmukaista validointiargumenttia: aiottua käyttötarkoitusta, riskiperusteista laajuutta, näyttöä kontrollipintojen toimivuudesta ja muutostenhallintaa, joka säilyttää validoidun tilan. Vahvimmat ohjelmat voivat esittää tiiviin näyttöpaketin, joka on linjassa CSV- periaatteiden ja -ohjeiden, kuten GAMP 5:n , kanssa.
Osassa 11 validointitodisteet korostavat tyypillisesti kontrollipintoja: käyttöoikeuksien hallintaa, auditointiketjun toimintaa, sähköisen allekirjoituksen toimintaa, säilytystä ja proseduraalista hallintaa. Validoinnin tulisi sisältää negatiivisia testejä (kiellettyjen toimien yritys), koska nämä testit tuottavat vahvimman näytön ehkäisystä.
| Artefakti | Mitä sen pitäisi osoittaa | Tarkastajan punainen lippu |
|---|---|---|
| Käyttötarkoitus ja soveltamisala | Mitkä tiedot ja päätökset ovat järjestelmän ja rajojen varassa. | Soveltamisala on epämääräinen; ”osa 11 koskee kaikkea” tai ”ei mitään”. |
| Riskien arviointi | Miksi kontrollit valittiin ja miksi niiden laajuus on asianmukainen. | Riskien ja testattujen asioiden välillä ei ole yhteyttä. |
| Protokollat ja tulokset | Todisteet kontrollipintojen toimivuudesta, mukaan lukien negatiiviset testitulokset. | Vain ”onnellisen polun” testausta; heikkoa ennaltaehkäisynäyttöä. |
| Poikkeamat ja ratkaisut | Miten testipoikkeamat tutkittiin ja suljettiin. | Ratkaisemattomat poikkeamat tai epävirallinen päättäminen ilman näyttöä. |
| Muuta ohjausta | Miten muutoksia arvioidaan ja testataan uudelleen. | Kerran saavutettu validoitu tila, jonka jälkeen tapahtuu hallitsemattomia muutoksia. |
10) Tarkastajat odottavat edelleen menettelytarkastuksia
Osa 11 ei ole pelkästään tekninen. Tarkastajat arvioivat rutiininomaisesti, tukevatko menettelyt teknisiä valvontatoimia. Yleisiä menettelyodotuksia ovat käyttöoikeuksien tarjoamisprosessit, säännöllinen käyttöoikeuksien tarkastus, koulutuksen/osaamisen dokumentointi, häiriöiden käsittely, tarvittaessa tarkastusketjun tarkastus ja muutoshallinnan hallinta.
Toistuva heikkous on etuoikeutettu käyttöoikeus. Jos järjestelmänvalvojat voivat muuttaa määrityksiä, luoda käyttäjiä tai muokata kriittisiä asetuksia ilman hallintaa, tekniset kontrollit menettävät uskottavuutensa. Menettelytapojen tulisi selkeästi määritellä, kenellä voi olla etuoikeutettuja rooleja, milloin niitä voidaan käyttää, miten käyttöä tarkastellaan ja miten poikkeukset dokumentoidaan.
11) Rajapinnat ja integraatiot: rajapintavikatilat
Integraatioissa tarkastuksissa löytyy usein aukkoja, koska "kuka teki mitä" -tiedot hajautuvat. Kun identiteetti, tila tai aikaleimat siirtyvät järjestelmien välillä, tarkastusketju voi pirstaloittua. Tarkastajat voivat kysyä, mikä järjestelmä on tiettyjen tietoelementtien rekisteröintijärjestelmä ja miten täsmäytys hoidetaan, kun järjestelmät ovat eri mieltä.
Puolistettavia integraatiomalleja ovat kunkin dataelementin selkeä omistajuus, määritellyt rajapintasopimukset, virheiden käsittely ja täsmäytysmekanismit. Jos päätietojen yhdenmukaistaminen on perusta, katso päätietojen synkronointi.
12) Tarkastusharjoitukset: 10 testiä, jotka voit suorittaa sisäisesti
Nopein tapa ymmärtää osan 11 valmius on suorittaa harjoituksia, jotka simuloivat tarkastajan käyttäytymistä. Jokaisen harjoituksen tulisi olla nopeasti suoritettavissa, ja tuotettujen todisteiden tulisi olla itsenäisiä ilman narratiivista rekonstruktiota.
- Yksilöllinen henkilöllisyystodistus: valitse tietue; todista, että luoja ja hyväksyjä ovat yksilöllisesti tunnistettuja ja valtuutettuja.
- Roolirajatesti: yritä kiellettyä toimintoa ei-valtuutetusta roolista; näytä esto ja lokitiedot.
- Auditointiketjun demo: muuta suojattua kenttää; näytä vanhat/uudet arvot, muutoksen syy, käyttäjä, aikaleima.
- Auditointiketjun tarkistus: näytä, miten tarkastusketjun merkinnät tarkistetaan (tarvittaessa) ja miten ongelmat ratkaistaan.
- Sähköisen allekirjoituksen merkitys: osoittaa, mitä allekirjoitus edustaa ja miten se esitetään asiakirjassa.
- Allekirjoituksen jälkeinen muutos: yritä muutosta allekirjoittamisen jälkeen; osoita hallintakäyttäytymistä ja näkyvyyttä.
- Etuoikeutetun pääsyn hallinta: näytä, miten järjestelmänvalvojan käyttöoikeudet hyväksytään, kirjataan ja tarkistetaan.
- Aikaleiman eheys: näytä aikavyöhykkeiden käsittely ja yhdenmukaisuus käyttöliittymässä, lokitiedostossa ja viennissä.
- Nouto paineen alla: noutaa koko tietuejoukko nopeasti; sisällyttää linkitetyt tietueet ja tarkastushistorian.
- Muutoshallinnan harjoitus: näytä viimeisin järjestelmämuutos, sen vaikutustenarviointi ja mahdolliset tarvittavat uudelleentestaukset.
13) Toteutuksen etenemissuunnitelma
Part 11 -asetelman parantaminen tarkoittaa harvoin teknologian lisäämistä. Tyypillisesti kyse on kontrollipintojen tiukentamisesta ja todisteiden noudettavuuden parantamisesta. Alla oleva etenemissuunnitelma on suunniteltu parantamaan puolustettavuutta nopeasti aiheuttamatta tarpeetonta lisäkuormitusta.
- Soveltamisala päätöksen perusteella: luetteloida säännellyissä päätöksissä käytetyt tiedot ja määritellä rekisteröintijärjestelmät.
- Lukitse identiteetti: yksilölliset tilit, pienimpien oikeuksien roolit, käyttöoikeuksien tarkistuksen tahdit, käyttöoikeuksien poistokuri.
- Määrittele suojatut kentät: mikä on tarkastettava, mikä vaatii muutoksen syyn, mikä vaatii allekirjoituksen.
- Todista tarkastuslokitoiminto: osoittaa suojattujen tietoelementtien turvallisen ja kohdennettavan historian.
- Vahvista sähköiset allekirjoitukset: merkitys, sidonta ja allekirjoituksen jälkeinen muutosten hallinta.
- Ohjauspintojen validointi: riskiperusteinen CSV-tiedosto, joka keskittyy käyttöoikeuksiin, tarkastuslokeihin, allekirjoituksiin, säilytykseen ja poikkeuksiin.
- Hallinnon toteuttaminen: etuoikeutettujen käyttöoikeuksien hallinta, muutostenhallinta, säännölliset tarkastelut, harjoitusrytmi.
Päätös
Osa 11 -valmius on päivittäinen toimintatapa. Tarkastajat testaavat sitä kysymällä, voidaanko sähköisiin tietueisiin luottaa ilman narratiivista rekonstruktiota, ovatko allekirjoitukset mielekkäitä ja sidottuja, ovatko tarkastusketjut täydellisiä ja turvallisia ja onko käyttöoikeus ja muutokset hallinnassa. Organisaatioilla, jotka pystyvät osoittamaan nämä kontrollit nopeasti, on yleensä lyhyempiä ja suppeampia tarkastuksia ja nopeampia tutkimuksia.
Katso lisätietoja määritelmistä tässä artikkelissa linkitetyiltä sanastosivuilta, mukaan lukien 21 CFR Part 11 , audit trail , electronic signatures , user access management , data integrity ja CSV . Nämä viitteet ovat valinnaisia; tässä artikkelissa kuvattu toimintamalli on tarkoituksella toimittajaneutraali.
