Masharti ya Mchakataji, viambatisho vimejumuishwa.
Sisi ndio mchakataji na wewe ndio mdhibiti. Hii ni hati ambayo mkaguzi wa ununuzi hufungua kwanza, hivyo ni ukurasa wenye viambatisho vyake vilivyounganishwa badala ya faili ya kupakua ambayo unahitaji kuomba.
- inaanza kutumika novemba 5, 2026
- nakala iliyotiwa saini kwa ombi
Kiambatisho cha Usindikaji wa Data
Wewe ndio mdhibiti, sisi ndio wachakataji, na tunafanya kazi kulingana na maagizo yako. Inatumika kiotomatiki unapokubali Masharti ya Huduma, hivyo hakuna kinachohitaji kusainiwa ili uwe nacho. Orodha ya wachakataji wadogo inafichuliwa na kutekelezwa katika msimbo, ukiukwaji unaripotiwa bila kuchelewa kisicho na lazima, viambatisho vilivyo hapa chini vinajazwa badala ya kuachwa wazi, na nakala iliyotiwa saini inapatikana kwa barua pepe badala ya mchakato mrefu wa ununuzi.
Wigo, majukumu na ujumuishaji
Kiambatanisho hiki cha Usindikaji wa Data ("DPA") kinaunda sehemu ya Masharti ya Huduma au makubaliano mengine yaliyoandikwa ("Makubaliano") kati ya Digital Socket LLC, kampeni yenye dhima ndogo iliyoundwa huko Delaware, Marekani, ikifanya biashara kama Transglot ("Transglot", "Msindikaji") na mteja ("Mteja", "Mdhibiti"), na linatumika popote tunapochakata Data Binafsi ya Mteja kwa niaba ya Mteja katika kutoa Huduma. Limeingizwa kwa marejeleo ndani ya Makubaliano na linaanza kutumika wakati Makubaliano yanapoanza; hakuna sahihi inayohitajika ili litufunge. Ambapo Mteja ni msindikaji mwenyewe anayetenda kwa niaba ya mdhibiti wa mtu wa tatu, Mteja ndiye muuzaji nje na DPA hii inatumika kana kwamba ndiye mdhibiti, na Mteja anathibitisha kuwa ana mamlaka kutoka kwa mdhibiti wake wa kuingia ndani yake kwa masharti hayo.
Ufafanuzi
"Sheria za Ulinzi wa Data" zinamaanisha sheria zote kuhusu usindikaji wa data binafsi zinazotumika kwa upande wowote, ikiwa ni pamoja na Kanuni ya Ulaya ya Ulinzi wa Data ya Jumla 2016/679 ("GDPR"), GDPR ya Uingereza na Sheria ya Ulinzi wa Data ya 2018, Sheria ya Shirikisho la Uswisi ya Ulinzi wa Data, Sheria ya Faragha ya Wateja wa California iliyorekebishwa ("CCPA") na sheria zinazolingana za faragha za majimbo ya Marekani. "Data Binafsi ya Mteja" inamaanisha data binafsi iliyo ndani ya Maudhui ya Mteja au vinginevyo inachakatwa na sisi kwa niaba ya Mteja. "Vifungu vya Kawaida vya Mkataba" au "SCCs" vinamaanisha vifungu vilivyoshikiliwa na Uamuzi wa Utekelezaji wa Tume (EU) 2021/914. "Kiambatanisho cha UK" kinamaanisha Kiambatanisho cha Uhamishaji wa Kimataifa wa Data kilichotolewa na Kamishna wa Habari wa Uingereza chini ya kifungu cha 119A cha Sheria ya Ulinzi wa Data ya 2018. "Msindikaji Mdogo" inamaanisha mtu wa tatu aliyehusishwa na sisi kuchakata Data Binafsi ya Mteja. "Mdhibiti", "msindikaji", "mhusika wa data", "data binafsi", "usindikaji", "uvunjaji wa data binafsi" na "mamlaka ya usimamizi" vina maana zilizotolewa katika GDPR, na istilahi zinazolingana katika sheria nyingine zina maana yao sawa.
Mpangilio wa utawala
Katika tukio la mgongano, mpangilio wa utawala ni: (a) Vifungu vya Kawaida vya Mkataba na Kiambatanisho cha UK, pale vinapotumika; (b) DPA hii; (c) masharti yoyote mengine ya ulinzi wa data katika Fomu ya Agizo; (d) sehemu iliyobaki ya Makubaliano. Hakuna kitu katika DPA hii kinachokusudiwa kugongana na majukumu ya upande wowote chini ya Sheria za Ulinzi wa Data, na kifungu chochote ambacho kingefanya hivyo kinapasuliwa kwa kiwango cha chini kinachohitajika kuondoa mgongano huo.
Muda
DPA hii inatumika tangu tarehe ya kuanza kwa Makubaliano hadi tusiposhikilia tena Data Binafsi yoyote ya Mteja, ambayo inaweza kuwa baada ya Makubaliano kuisha kwa sababu ya ratiba za kufuta zilizoko katika kifungu cha 13. Majukumu yake yanaendelea baada ya kumalizika kwa muda mrrefu tunavyoshikilia Data Binafsi yoyote ya Mteja, na majukumu ya usiri yanaendelea milele kwa kiwango kinachohitajika na Sheria za Ulinzi wa Data.
Usindikaji kulingana na maagizo yaliyorekodiwa
Tunachakata Data Binafsi ya Mteja kulingana na maagizo yaliyorekodiwa ya Mteja pekee, ikiwa ni pamoja na kwa uhamishaji kwenda nchi ya tatu, isipokuwa tukitakiwa kufanya hivyo na sheria ambayo tunategemea, ambapo tutamwambia Mteja kuhusu hitaji hilo kabla ya usindikaji isipokuwa sheria inapokataza kwa sababu muhimu za maslahi ya umma. Makubaliano, DPA hii, Nyaraka na usanidi ambao Mteja huweka katika bidhaa (miradi, eneo, viunganishi, michango ya webhook, swichi za uhifadhi, swichi ya kumbukumbu ya tafsiri na injini na mipangilio ya ubora inayopatikana kwa Mteja) pamoja huunda maagizo kamili yaliyorekodiwa ya Mteja. Tutamwambia Mteja ikiwa, kwa maoni yetu, agizo linakiuka Sheria za Ulinzi wa Data, na tunaweza kusimamisha usindikaji husika hadi lipigwe marufuku au lirekebishwe badala ya kulitekeleza.
Kikomo cha madhumuni, na kile ambacho hatufanyi kamwe
Tunachakata Data Binafsi ya Mteja ili kutoa, kulinda, kusaidia na kudumisha Huduma kwa Mteja pekee, na bila madhumuni yoyote ya kujitegemea yetu wenyewe. Hatuuza Data Binafsi ya Mteja, hatuishiriki kwa matangazo ya tabia ya muktadha-mwingine, hatuiunganishi na data binafsi tunayopokea kutoka vyanzo vingine isipokuwa ikiwa inaruhusiwa na Sheria za Ulinzi wa Data kwa mtoa huduma, na hatuitumii kufundisha, kurekebisha au kutathmini modeli yoyote ya kujifunza kwa mashine. Wasindikaji wadogo wetu wa AI wanaiachakata kwa ajili ya inferensi pekee, chini ya masharti ya kibiashara yanayokataza mafunzo juu yake. Tunaweza kuunda na kutumia takwimu zilizojumlishwa au zisizo na utambulisho ambazo hazitambui wala Mteja wala mhusika wowote wa data, na hatutajaribu kuwatambua tena.
Usiri wa wafanyakazi
Tunahakikisha kuwa kila mtu aliyeidhinishwa kuchakata Data Binafsi ya Mteja anategemea wajibu unaofaa wa usiri, iwe wa mkataba au wa kisheria, ambao unaendelea baada ya kumalizika kwa ushiriki wao. Upatikanaji unatolewa kulingana na kanuni ya upendeleo mdogo zaidi, ukikomiwa kwa kile ambacho mtu anahitaji kutekeleza jukumu lake, ukikaguliwa mara kwa mara na kuvuliwa haraka pale jukumu linapobadilika au mtu anapoondoka. Wafanyakazi wenye upatikanaji wanapokea mafunzo ya ulinzi wa data na usalama yanayofaa kwa jukumu lao.
Usalama wa usindikaji
Tunatekeleza na kudumisha hatua za kiufundi na za kimuundo zilizowekwa katika Kiambatanisho II, tukizingatia hali ya sanaa, gharama za utekelezaji na asili, wigo, muktadha na madhumuni ya usindikaji, pamoja na hatari kwa wahusika wa data. Tunaweza kusasisha hatua hizo kadri muda unavyoenda ikiwa kiwango cha jumla cha ulinzi hakipunguzwi kwa kiasi kikubwa wakati wa kipindi cha usajili chenye malipo. Kiambatanisho II kinaelezea mapengo yetu pamoja na udhibiti wetu, kwa makusudi: kiambatanisho cha hatua ambacho kinaorodhesha nguvu pekee si nyaraka ambayo mkaguzi anaweza kutegemea.
Wasindikaji wadogo, arifa na upinzani
Mteja anatoa idhini ya jumla iliyoandikwa kwa sisi kuhusisha Wasindikaji Wadogo, katika makundi yaliyoelezwa katika hati ya Wasindikaji Wadogo, na hasa anaidhinisha wale walio katika orodha ya wasindikaji wadogo iliyotolewa chini ya Kiambatanisho III tangu tarehe ya kuanza. Tunaweka kwa kila Msindikaji Mdogo majukumu ya ulinzi wa data yasiyo na ulinzi mdogo kuliko yale yaliyo katika DPA hii kupitia mkataba ulioandikwa, na tunabaki kuwajibika kikamilifu kwa Mteja kwa utendaji wa majukumu ya Msindikaji Mdogo. Tutampa Mteja angalau arifa ya siku thelathini, kwa barua pepe kwa Wenye Akaunti, kabla ya Msindikaji Mdogo mpya kuanza kuchakata Data Binafsi ya Mteja. Mteja anaweza kupinga kwa sababu zinazolingana na zilizorekodiwa za ulinzi wa data ndani ya kipindi hicho, ambapo tutafanya kazi kwa nia njema kutoa mabadiliko katika usanidi au mbadala unaokwepa usindikaji huo; ikiwa hatuwezi ndani ya muda unaofaa, Mteja anaweza kumaliza usajili husika bila adhabu na kupokea refund ya sehemu ya ada zilizolipiwa mapema ambazo hazijatumika.
Kusaidia kwa maombi ya watu waliohusika na data
Tukizingatia asili ya usindikaji, tunamsaidia Mteja kwa hatua zinazofaa za kiufundi na za kimuundo, kadiri inavyowezekana, katika kutekeleza wajibu wa Mteja wa kujibu mtu anayetumia haki za ufikiaji, marekebisho, kufutwa, kizuizi, uhamishaji au upinzani. Bidhaa yenyewe ndio safu ya kwanza ya msaada huo: Wamiliki wa Akaunti na wasimamizi wa eneo la kazi wanaweza kutafuta, kuhariri na kufuta maudhui ya mradi, kusimamia wanachama na majukumu, na kupata maudhui ya mradi kupitia sehemu ya kuvuta ya API, kiolesura cha mstari wa amri, kifurushi cha utoaji au kiunganishi cha hifadhi kwenye mpango wa kulipia, na Wamiliki wa Akaunti wanaweza kufuta eneo la kazi. Pale ambapo bidhaa haiwezi kujibu ombi, tutasaidia kwa ombi ndani ya kipindi kinachofaa na bila malipo kwa kiasi kinachofaa cha maombi. Ikiwa mtu anayehusika na data atawasiliana nasi moja kwa moja kuhusu Data Binafsi ya Mteja, hatujibu wenyewe kwa undani; tutawaambia wasiliane na Mteja na, isipokataliwa, tutamwambia Mteja haraka.
Kusaidia kwa tathmini za athari
Tukizingatia asili ya usindikaji na taarifa zinazopatikana kwetu, tunamsaidia Mteja katika kutimiza majukumu yake chini ya Vifungu 32 hadi 36 vya GDPR na vitendawili vyake, ikiwa ni pamoja na tathmini za athari za ulinzi wa data na ushauri wa awali na mamlaka ya usimamizi. Kivitendo, hii inamaanisha kutoa DPA hii, Kiambatisho II, ufichuzi wa Kituo cha Uaminifu, ratiba ya uhifadhi katika Sera ya Faragha, nyaraka zetu za usalama na majibu ya maandishi yanayofaa kwa maswali ya usalama au faragha. Tunaweza kutoza ada kwa msaada unaovuka kwa kiasi kikubwa kiasi kinachofaa, kwa viwango vyetu vya sasa vya huduma za kitaalamu, na tutaeleza hilo kabla ya kufanya kazi badala ya baadaye.
Arifa ya ukiukwaji wa data binafsi
Tunampa Mteja arifa bila kuchelewa kisicho na lazima, na katika hali yoyote ndani ya saa sitini na mbili, baada ya kujua ukiukwaji wa data binafsi unaohusu Data Binafsi ya Mteja. Arifa inaelezea, kwa kiasi kinachojulikana wakati huo na kusasishwa tunapojifunza zaidi: asili ya ukiukwaji ikiwa inawezekana ikijumuisha aina na idadi takribani ya watu waliohusika na rekodi zinazohusika; matokeo yanayotarajiwa; hatua zilizochukuliwa au zilipopendekezwa kukabiliana nazo na kupunguza athari zake; na sehemu ya mawasiliano kwa taarifa zaidi. Tunashirikiana na Mteja na kuchukua hatua ambazo Mteja anaomba kwa busara ili kumsaidia katika uchunguzi wake mwenyewe na utoaji wa arifa. Arifa si, na haitafsiriwa kama, kukubali kosa au dhima. Hatuchelewesha arifa ili kukamilisha uchunguzi kwanza.
Kufuta na kurudisha
Chaguo la Mteja, tunafuta au kurudisha Data Binafsi ya Mteja mwishoni mwa utoaji wa huduma, na kufuta nakala zilizopo, isipokuwa sheria ambayo tunategemea inahitaji uhifadhi. Katika bidhaa, hii inafanya kazi kama ifuatavyo: kughairi usajili kunahamisha Akaunti hadi kwenye mpango wa Bure, ambao unajumuisha eneo moja la kazi, na kila eneo lingine la kazi linakuwa la kusoma pekee na lifutwa baada ya siku 30, au mapema zaidi kwa eneo la kazi lililopitia hali ile hivi karibuni kama kifungu 13 cha Masharti ya Huduma kinavyoelezea, isipokuwa Mteja atasasisha au kulihama kwanza; kufuta eneo la kazi kulifanya liwe la kusoma pekee kwa siku 30, ambapo Mmiliki wa Akaunti anaweza kulirejesha, na baada ya kipindi hicho eneo la kazi linaondolewa kabisa kutoka kwenye hifadhidata hai, ikiwa ni pamoja na miradi, tafsiri, historia ya toleo, rekodi za matumizi, rekodi za utoaji wa webhook, picha za skrini na matukio ya ukaguzi; kufunga Akaunti kunafuta kila eneo la kazi lililo juu yake kwa njia ileile na kunahifadhi ankara za Akaunti kwa miaka 7; kufuta ingizo la Mtumiaji ni papo hapo na halirejelekwi. Maudhui ambayo Mteja anapata kupitia API, kiolesura cha mstari wa amri, kifurushi cha utoaji au kiunganishi cha hifadhi hayako chini ya udhibiti wetu tangu wakati tunapoyatoa. Nakala za hifadhi zilizosimbwa kwa njia fiche hazifikiiwa na uondoaji huu na huisha kulingana na ratiba zilizo katika Kiambatisho II; wakati zipo zimetengwa, zimesimbwa kwa njia fiche na hurudishwa tu kwa ajili ya urejeshaji wa maafa, kamwe si kurudisha eneo la kazi lililoondolewa kwenye huduma. Ombi la maandishi la kurudisha katika muundo uliopangwa lililofanywa kabla ya kufutwa litatekelezwa mara moja, bila malipo, ndani ya kipindi kinachofaa.
Haki za ukaguzi na taarifa
Tunampa Mteja taarifa zinazohitajika kwa busara kuonyesha utekelezaji wa DPA hii na Kifungu cha 28 cha GDPR, na kuruhusu na kuchangia ukaguzi, ikiwa ni pamoja na uchunguzi, unaofanywa na Mteja au mkaguzi aliyeagizwa naye. Katika hatua ya kwanza, jukumu hilo linatimizwa kupitia DPA hii, Kiambatisho II, Kituo cha Uaminifu, ukurasa wa usalama na majibu yetu yaliyokamilishwa ya maswali ya usalama. Pale ambapo hayatoshi kweli kwa ajili ya wajibu wa udhibiti wa Mteja, Mteja anaweza kufanya ukaguzi mara moja katika kipindi cha miezi kumi na miwili, baada ya kutoa arifa ya siku thelathini kwa maandishi, wakati wa masaa ya biashara, bila kuvuruga shughuli zetu kisivyo na sababu, chini ya majukumu ya usiri, ikipunguzwa kwenye mifumo na rekodi zinazohusiana na data ya Mteja mwenyewe, na kwa gharama ya Mteja. Mamlaka ya usimamizi inayotekeleza nguvu ya kisheria haijadhibitiwa na vikwazo hivyo. Mkaguzi hawezi kuwa mshindani wetu, na tunaweza kutaka ahadi tofauti ya usiri kutoka kwao.
Uhamisho wa kimataifa na Vifungu vya Kawaida vya Mkataba
Pale ambapo usindikaji wetu wa Data Binafsi ya Mteja unahusisha uhamisho kutoka Eneo la Kiuchumi la Ulaya kwenda nchi ambayo haijafunikwa na uamuzi wa uwiano, Vifungu vya Kawaida vya Mkataba vinajumuishwa na kuwa sehemu ya DPA hii na vinatumika kama ifuatavyo. Moduli Mbili (mdhibiti hadi msindikaji) inatumika pale ambapo Mteja ni mdhibiti. Moduli Tatu (msindikaji hadi msindikaji) inatumika pale ambapo Mteja ni msindikaji yeye mwenyewe. Kifungu 7 (kifungu cha kujiunga) kinatumika. Katika Kifungu 9, Chaguo 2 (ruhusa ya jumla kwa maandishi) limechaguliwa, huku muda wa arifa ukitajwa katika kifungu 09 hapo juu. Katika Kifungu 11, lugha hiari ya utatuzi wa migogoro huru haijachaguliwa. Katika Kifungu 17, Vifungu vinadhibitiwa na sheria za Jamhuri ya Ireland isipokuwa pande zikubaliane sheria nyingine ya nchi wanachama wa EU katika Fomu ya Agizo. Katika Kifungu 18(b), migogoro inatatuliwa mbele ya mahakama za Jamhuri ya Ireland kwa msingi huo huo. Kiambatisho I(A) ni pande husika, Kiambatisho I(B) ni maelezo ya uhamisho, Kiambatisho I(C) ni mamlaka yenye mamlaka ya usimamizi, Kiambatisho II ni hatua za kiufundi na za shirika, na Kiambatisho III ni orodha ya wasindikaji wadogo, kila moja kama ilivyoelezwa hapa chini.
Ufalme wa Muungano na Uswisi
Kwa uhamisho unaotegemea UK GDPR, Kiambatanisho cha UK kinajumuishwa na kukamilishwa kama ifuatavyo: Jedwali 1 limekamilishwa na Kiambatisho I(A); Majedwali 2 na 3 yamekamilishwa na kifungu 15 na Viambatisho I na II vya DPA hii, huku SCCs Zilizoidhinishwa za EU zikiwa toleo linalotegemewa; na katika Jedwali 4, hakuna upande unaoweza kumaliza Kiambatanisho wakati Kiambatanisho Kilichoidhinishwa kinapobadilika. Kwa uhamisho unaotegemea sheria za Uswisi, marejeo katika SCCs kwa GDPR yanasomwa kama marejeo kwa Sheria ya Shirikisho ya Uswisi juu ya Ulinzi wa Data, mamlaka yenye mamlaka ni Kamishna wa Shirikisho wa Ulinzi wa Data na Habari, marejeo kwa nchi wanachama hayamnyima mtu binafsi wa data nchini Uswisi haki ya kushtaki mahali pa makazi yake ya kawaida, na SCCs zinulinda data ya mashirika ya kisheria hadi sheria za Uswisi zitakapoacha kuhitaji hivyo.
Ufikiaji wa serikali na utekelezaji wa sheria
Ikiwa tutapokea ombi lenye nguvu ya kisheria kutoka kwa mamlaka ya umma kwa Data Binafsi ya Mteja, tutafanya yafuatayo: kulikagua kwa ajili ya uhalali na wigo na kulipinga pale ambapo kuna sababu za busara za kuzizingatia kuwa si halali; kufichua tu kiwango cha chini kinachohitajika na ombi; na kumtaarifu Mteja haraka kwa maelezo ya kutosha ili kujibu, isipokuwa ikiwa imezuiwa kisheria, ambapo tutatumia juhudi za busara kupata msamaha wa uzuio huo na kutafuta hatua ya muda kuruhusu ufichuzi. Tunaweka rekodi ya maombi tunayopokea na majibu tunayotoa, na tunayafanya yapatikane kwa Mteja na kwa mamlaka ya usimamizi kwa ombi kwa kiwango sheria inavyoruhusu. Hatujapokea ombi la serikali lililotutaka kujenga au kudumisha utaratibu wa jumla wa ufikiaji wa Data Binafsi ya Mteja, na hatutaujenza kwa hiari.
Masharti ya mtoa huduma wa California
Kwa taarifa binafsi zinazotegemea CCPA, Mteja ni biashara na sisi ni mtoa huduma. Tumekatazwa, na hatutauza au kushiriki taarifa hizo binafsi; kuzihifadhi, kuzitumia au kuzifichua kwa madhumuni yoyote isipokuwa madhumuni ya biashara yaliyobainishwa katika Mkataba au kama inavyoruhusiwa vinginevyo na CCPA; kuzihifadhi, kuzitumia au kuzifichua nje ya uhusiano wa moja kwa moja wa biashara kati ya pande; au kuzichanganya na taarifa binafsi zilizopokelewa kutoka chanzo kingine, isipokuwa kama CCPA inavyomruhusu mtoa huduma kufanya. Tunathibitisha kwamba tunaelewa na tutatekeleza vikwazo hivi. Tutamtaarifu Mteja ikiwa tutabaini kuwa hatuwezi tena kuzitimiza. Mteja anaweza kuchukua hatua za busara na zinazofaa kusimamisha na kurekebisha matumizi yasiyoruhusiwa, kwa kutumia haki za ukaguzi katika kifungu 14. Tunatoa kiwango sawa cha ulinzi wa faragha kama CCPA inavyohitaji kutoka kwa biashara.
Sheria nyingine za faragha za majimbo ya Marekani
Pale ambapo sheria kamili ya faragha ya jimbo inatumika na inahitaji mkataba wa msindikaji wenye masharti maalum, DPA hii ndiyo mkataba huo: inaweka asili na madhumuni ya usindikaji, aina ya data, muda, haki na majukumu ya pande zote mbili, wajibu wetu wa usiri, ushirikishaji wetu wa wasindikaji wadogo chini ya masharti sawa ya maandishi, usaidizi wetu kwa maombi ya haki za watumiaji na kwa majukumu ya usalama, wajibu wetu wa kufuta au kurudisha mwishoni mwa huduma, na wajibu wetu wa kufanya taarifa zinazohitajika kuonyesha utekelezaji zipatikane na kuruhusu tathmini ya busara. Tunafanya kazi kama msindikaji au mtoa huduma chini ya sheria hizo na kamwe si kama mdhibiti wa Data Binafsi ya Mteja.
Wajibikifu chini ya kiambatanisho hiki
Wajibikifu wa kila upande unaojitokeza kutoka au kuhusiana na DPA hii, iwe katika mkataba, kosa la kiraia au nadharia nyingine yoyote, unategemea vikwazo na viungo vya wajibikifu katika Mkataba, na marejeo yoyote katika vikwazo hivyo kwa wajibikifu wa upande yanamaanisha wajibikifu wa jumla wa upande huo chini ya Mkataba na DPA hii pamoja. Hakuna kitu katika kifungu hiki kinachopakua haki za mtu binafsi wa data chini ya Vifungu vya Kawaida vya Mkataba au chini ya Sheria ya Ulinzi wa Data, na hakuna kitu kinachopakua wajibikifu ambao hauwezi kupunguzwa kisheria.
Mabadiliko ya kiambatanisho hiki
Tunaweza kusasisha DPA hii pale ambapo inahitajika kuakisi mabadiliko katika Sheria ya Ulinzi wa Data, utaratibu mpya au uliorekebishwa wa uhamisho, uamuzi wa mamlaka ya usimamizi au mahakama, au mabadiliko makubwa katika jinsi Huduma inavyosindika Data Binafsi ya Mteja, mradi sasisho halipunguze kwa kiasi kikubwa ulinzi unaotolewa kwa Data Binafsi ya Mteja. Tunatoa arifa ya angalau siku thelathini ya sasisho kubwa, kwa barua pepe na kwenye ukurasa huu, na tunabadilisha tarehe ya kuanza kutumika iliyo juu. Tunaweka toleo lililopitwa likipatikana kwa ombi.
Kupata nakala iliyotiwa saini, au mabadiliko
DPA hii inatufunga bila saini, kwa hivyo Mteja haihitaji ili kulindwa. Ikiwa mchakato wako unahitaji nakala iliyotiwa saini kwa rekodi zako, au ikiwa unataka kuleta mabadiliko, andika barua kwa privacy@transglot.ai ukitaja jina la shirika la kisheria, anwani iliyosajiliwa, mwasiliani wa arifa na mtiaji saini, na tutarejesha nakala iliyotiwa saini. Tunajibu maswali ya usalama na faragha kutoka anwani ileile, na Kituo cha Uaminifu kinabeba kifurushi ambacho wahakimu wengi wanahitaji kabla hajaandika kwa mtu yeyote.
Annex I(A): the parties
Data exporter: the Customer, being the person or company that holds the Account, as named on the Account or on the Order Form, acting as controller (or as processor where clause 01 applies) in respect of Customer Personal Data processed through the Service. Contact details: the Account Owners' email addresses and the notice contact given on the Order Form. Activities relevant to the transfer: use of a cloud localization platform to store, translate, review, deliver and manage software and content strings. Signature and date: as recorded by acceptance of the Agreement, or as executed under clause 22. Data importer: Digital Socket LLC, kampeni yenye dhima ndogo iliyoundwa huko Delaware, Marekani, ikifanya biashara kama Transglot, acting as processor. Contact details: privacy@transglot.ai. Activities relevant to the transfer: provision of the Service described in the Agreement. Role: processor.
Annex I(B): description of the processing
Categories of data subjects: the Customer’s personnel and contractors who hold a login (Account Owners and Billing Members, and workspace admins, developers, reviewers and translators); the Customer’s own end users, customers and other individuals to the extent their personal data appears inside source strings, translations, glossary entries, comments, screenshots or imported files; and the Customer’s billing and notice contacts. Categories of personal data: identity and contact data (name, email address, login identifier, Account, workspace and role); authentication data (hashed password, second factor enrolment, federated identity subject identifiers, API token digests); usage and technical data (IP address, user agent, pages and endpoints accessed, request and run identifiers, timings, outcomes, error traces, audit records); billing data (billing contact, billing address, tax identifiers, payment method token and card metadata held by the payment processor); content data (whatever personal data the Customer chooses to place in project content, which is under the Customer’s control and which the Acceptable Use Policy asks the Customer to keep free of payment card data, government identifiers, credentials and special category data). Sensitive data: none is requested or required, and none should be submitted; where the Customer nonetheless submits it, the restrictions and safeguards are those in Annex II applied to all Customer Content, and the Customer remains responsible for its lawful basis. Frequency: continuous, for the duration of the Agreement, on the Customer’s instruction. Nature and purpose: hosting, storage, indexing, machine translation, quality checking, translation memory matching, glossary enforcement, review workflow, delivery and transmission through the API, webhooks, connectors and the delivery bundle, together with support, security and billing. Duration of processing: the term of the Agreement plus the retention periods stated in the Privacy Policy and clause 13 of this DPA. Subprocessor processing: for the purposes, and for the durations, set out in Annex III and in the Trust Center.
Annex I(C): competent supervisory authority
Where the SCCs apply on the basis of Article 3(1) of the GDPR, the competent supervisory authority is the one in the member state in which the data exporter is established. Where they apply because the exporter is not established in the European Economic Area but is caught by Article 3(2), the competent authority is the one in the member state in which the exporter’s Article 27 representative is established. Where they apply on the basis of Article 3(2) and no representative is appointed, the competent authority is the one in the member state in which the data subjects whose personal data is transferred are located. For UK transfers the competent authority is the Information Commissioner’s Office; for Swiss transfers, the Federal Data Protection and Information Commissioner.
Annex II: encryption and key handling
Data in transit is protected with TLS 1.2 or better at the edge, and connections below that are refused. Passwords are hashed with bcrypt at a cost factor of 12 and are never stored or logged in plaintext. API tokens and delivery keys are stored as SHA-256 digests, are displayed once at creation and cannot be recovered afterwards; publishable in-context keys are deliberately public identifiers bound to an origin allowlist rather than secrets, and are documented as such. Third party credentials, connector tokens, SSO configuration secrets and webhook signing secrets are held in encrypted columns using authenticated application-level encryption. Database backups are encrypted with AES-256 by the backup tool itself, independently of any provider-side encryption, and file backups are held in a password-encrypted repository. Two honest gaps: the live database and application volumes are not disk-encrypted, and server-side encryption of the object store is not asserted in our own configuration. We state both here rather than letting a reviewer discover them in diligence.
Annex II: access control and identity
Every query in the application is scoped by Account, workspace and project, and a cross-tenant identifier answers 404 rather than 403 so that the existence of another tenant’s record never leaks. The two Account roles (Owner and Billing), the four workspace roles (admin, developer, reviewer and translator), eighteen project abilities and per-project and per-language grants are available on every plan including Free, so least privilege is never a paid upgrade. Two-factor authentication with time-based one-time codes and recovery codes, and passkeys, are available on every plan, and an Account Owner can require a second factor for an entire workspace, enforced at the workspace boundary so that federated and single sign-on doors cannot bypass it. SAML 2.0 single sign-on with just-in-time provisioning, generic OpenID Connect, SCIM 2.0 provisioning and de-provisioning, and the ability to switch off password login for a workspace are available on the Enterprise plan. API access uses scoped tokens with optional expiry. Internal administrative access is least privilege, and operator impersonation of a customer’s login is time-limited to thirty minutes and writes an audit record when it starts and when it ends.
Annex II: logging, monitoring and audit
Security-relevant events are written to an append-only audit trail: sign-in and single sign-on events, second factor and workspace MFA policy changes, member invitations, joins, role changes and removals, custom role changes, token and key creation and revocation, integration and connector connection and disconnection, review policy changes, branding changes, SCIM provisioning events, workspace rename and deletion requests. Plan, billing and spend cap changes, changes to the Account’s members and the closing of the Account are written to the Account’s own audit trail in the same way. Each record carries the workspace or the Account, the actor, the action, the target, structured metadata, the source IP address and the time, and the model layer refuses updates and deletes, so a record cannot be edited after the fact; on the Account’s trail the IP address is removed after 395 days. On the Enterprise plan the whole trail, the Account’s included, can be exported as CSV. Append-only is enforced in the application layer and there is no cryptographic hash chain or signature over the log, so we do not describe it as tamper-evident. Application errors are collected by an error tracker we host ourselves, configured not to send personally identifying information and not to capture request bodies, which is the setting that actually keeps customer strings out of a stack trace. Operational metrics are retained for thirty days.
Annex II: application and network security
Public endpoints are rate limited: the REST API at sixty requests a minute per token, the delivery endpoint at three hundred a minute per key and address, sign-in at five a minute per email and address, and registration at five a minute and twenty an hour per network block, with separate buckets for the other public doors. Outbound webhooks are signed HMAC-SHA256 over the timestamp and the raw body, sent as an explicit signature header and a timestamp header, and compared in constant time; the timestamp is published so the receiver can enforce its own replay window, and we are explicit that no server-side tolerance is enforced on our side. Inbound forge webhooks are verified by signature, with the delivery identifier as the replay guard. Cross site request forgery protection is applied to every state-changing browser request, sessions expire after 120 minutes of inactivity, sensitive actions require password re-confirmation within a 3 hour window, password reset links expire after 60 minutes, and destructive actions require typing the workspace name or re-entering a password. A frame-ancestors content security policy is applied; we do not claim a broad content security policy, because we do not yet ship one.
Annex II: pseudonymisation and data minimisation
Usage metering records counts of words and tokens, never the body of a request. The shared exact-match translation memory pool stores the linguistic pair keyed by a hash of the source, together with plural forms and reuse counters, and stores no user column and no team column at all, so an entry cannot be traced to a person; the key name, file path, screenshots, comments and every other piece of surrounding context are stripped. Human-reviewed memory entries carry a workspace identifier, which functions as a hard tenant fence on the near-match query rather than as attribution, and that is why a reviewed entry is never returned to another workspace. Any project can leave the pool entirely with a per-project switch on every plan, which stops it both contributing and drawing. In-context screenshots are held on a private store with no public path and are served only through short-lived signed URLs.
Annex II: resilience, backup and recovery
The database is backed up continuously with write-ahead log archiving and periodic full and differential backups, retaining two full backups and seven differentials, encrypted with AES-256 by the backup tool. Application file storage is snapshotted nightly into a password-encrypted repository retaining thirty daily, twelve weekly and twelve monthly snapshots, with an integrity verification pass on each run. Restore procedures are documented and exercised. Backups are isolated from the production credentials that could delete them, and they are restored for disaster recovery only, never to return a purged workspace to service. Deployment images are retained for the last several releases so that a rollback is a minute rather than a rebuild.
Annex II: secure development and change management
Changes are made through version control with peer review, an automated test suite, static analysis and dependency scanning, and container image vulnerability scanning in the build pipeline, and a failing gate blocks the release rather than warning about it. Test environments do not use production customer data. Secrets are held encrypted at rest in the deployment repository and injected at runtime rather than committed. Several product claims are themselves enforced by tests: a translation engine that becomes reachable without a subprocessor disclosure row fails the build, and the advertised overage rate is pinned to the rate the system charges. Third party components are tracked and patched, and a build is refused when a scanner reports a vulnerability above threshold.
Annex II: organisational measures
Access to production is limited to the personnel who need it, granted individually, and removed on role change or departure. Personnel are bound by confidentiality obligations that survive their engagement, and receive security and data protection guidance appropriate to their role. We operate a documented incident response process with defined severities, an on-call rotation, alerting on service health and background job health, and post-incident review. We publish a vulnerability disclosure policy with a safe harbour for good faith research and a security address that is monitored. We hold no third party security certification today: a SOC 2 Type II audit is in progress and an AI management system standard is being pursued, and the compliance status published on our site is rendered from a configuration value that cannot show a certificate we do not hold.
Annex II: retention and deletion measures
Scheduled jobs enforce the retention windows published in the Privacy Policy rather than leaving them as intentions: translation version history at 180 days with a floor of the newest 20 per string, notifications at 90 days, resolved comment threads at 365 days from resolution, the activity feed at 180 days, assistant conversations at 90 days, in-context screenshots at 90 days with the stored object deleted alongside the record, connector sync records at 90 days keeping the latest per connection, referral click records at 90 days, unreviewed and unused translation memory entries at 90 days, failed background jobs at 7 days, expired API tokens 24 hours after they lapse, federated login correlation records at their own expiry, signup integrity signals 90 days after the Account was created or the pair was last seen, sign-up refusal records at 90 days, welcome words velocity records at 30 days for a domain and 24 hours for a network, sign-up allowlist entries at the expiry an operator set, never more than 365 days, Accounts never verified and holding no workspace at 30 days, welcome words, trial and card fingerprint records at 1,095 days, and the IP address on an Account’s audit trail at 395 days. Deletion runs in bounded batches rather than as one unbounded operation. Workspace deletion is a 30 day reversible grace period followed by a cascading purge of the live database. Webhook delivery records have no time-based prune today and are removed with their endpoint or their workspace.
Annex II: measures for transfers
For transfers to subprocessors we rely on the contractual measures in clause 15 together with these supplementary measures: transport encryption on every hop; contractual prohibitions on training, on onward transfer without equivalent protection, and on processing outside our instructions; a published and code-enforced disclosure list so that no undisclosed vendor can be routed customer text; the ability for a customer to disable the optional features that engage a conditional subprocessor, including the semantic translation memory feature and the per-project translation memory switch; retention windows enforced by scheduled jobs so that transferred data does not accumulate indefinitely; and the government access commitments in clause 17, including challenge, minimisation, notification and record keeping.
Kiambatisho III: wasaidizi wa usindikaji
Orodha yenye mamlaka na ya sasa ya wasindikaji wadogo inadumishwa na sisi na kutokea kwa Mteja anapoomba chini ya makubaliano ya kutofichua taarifa, kwa kuandika barua pepe privacy@transglot.ai. Aina, madhumuni, eneo na masharti ambayo kila mmojawapo anashirikishwa yanachapishwa katika Kituo cha Uaminifu na kufupishwa katika hati ya Wasindikaji Wadogo, ambayo imejumuishwa katika Kiambatisho hiki kwa marejeleo. Inashikiliwa mahali pamoja badala ya kunakiliwa katika ukurasa huu kwa makusudi: orodha iliyoandikwa upya katika hati ya kisheria ni orodha inayokosa usahihi siku mtengaji anapobadilika, na kiambatisho kilichokale ni mbaya zaidi kuliko kiungo. Kuanzia tarehe ya kuanza kutumika, aina ni: tafsiri ya AI, ukaguzi wa ubora unaofanywa kiotomatiki, utoaji wa msamiati na mapendekezo ya maono katika muktadha, yanayosindikwa nchini Marekani na yanayoshirikishwa wakati kipengele cha AI kinapotumiwa; embeddings za maandishi kwa ajili ya kumbukumbu ya tafsiri ya semantiki, zinazosindikwa nchini Marekani na zinazoshirikishwa tu mradi unapowasha kipengele hicho, ambacho kimezimwa chaguomsingi; injini mbadala ya tafsiri hiari inayopatikana kupitia router ya API nchini Marekani na inayohifadhiwa Singapore, inayoshirikishwa tu mtendaji anapoelekeza ngazi kwake, ambayo imezimwa chaguomsingi; uhosting wa wingu, hifadhidata na uhifadhi wa vitu, katika eneo lililothibitishwa wakati wa utekelezaji na linaloshirikishwa daima; usindikaji wa malipo, nchini Marekani na Umoja wa Ulaya, unao shirikishwa tu kwa mipango yenye malipo; utoaji wa barua pepe za shughuli, unaoshirikishwa daima; na ujumbe wa usaidizi ndani ya bidhaa, unaoshirikishwa tu mtumiaji anapowasha ujumbe wa usaidizi. Pale ambapo mteja anatoa vitambulisho vyake mwenyewe kwa ajili ya njia mbadala ya tafsiri ya mashine hiari, mteja ndiye anayedhibiti uhamisho huo na mtengaji si msindikaji mdogo wetu.
viunganishi 41, tayari vimejengwa.
Sheria haipaswi kuwa sehemu inayochelewesha.
Nyaraka kumi na nne, kila moja kwenye URL yake, ikiwa na orodha ya wasindikaji mdogo, msimamo wa data na hali ya utii iliyochapishwa kama ilivyo leo.