@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix edu: <https://knobit.org/def/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix schema: <https://schema.org/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<https://knobit.org/id/task/dso-environments-capacity/C1> a edu:Question ;
    rdfs:label "C1 (3 points)"@en ;
    dcterms:license <https://creativecommons.org/licenses/by/4.0/> ;
    owl:sameAs <https://bitbucket.org/reffa/ontology/id/task/dso-environments-capacity/C1> ;
    schema:hasPart <https://knobit.org/id/register/data-storage-operations#SO-201> ;
    schema:identifier "C1" ;
    schema:position 1 ;
    schema:text "Production data outside production, 1 each. (a) UAT (EV-003) is called masked, but the personal identification code is hashed with SHA-256 and no secret - anyone can hash a known code and find the person - and the IBAN is kept: together the data stays re-identifiable, so it is still personal data (GDPR recital 26). The answer says why the combination, not each field, fails. (b) It fixes it: tokenisation with a secret key held outside the environment (or synthetic accounts for payment tests), and each refresh approved by the data owner (EV-003 has no refresh approval). (c) SIT (EV-002) loads an unmasked production copy: reported and changed to masked or synthetic data."@en .

edu:Question rdfs:label "Question"@en,
        "Küsimus"@et .

<https://knobit.org/id/register/data-storage-operations#SO-201> rdfs:label "dso-environments-capacity C1: production data outside production"@en .