ਜਾਣੋ ਕਿ ਇਕ ਵੈੱਬ ਐਪ ਕਿਵੇਂ ਡਿਜ਼ਾਇਨ ਅਤੇ ਬਣਾਇਆ ਜਾਵੇ ਤਾਂ ਜੋ ਡੇਟਾ ਐਕਸੈਸ ਬੇਨਤੀਆਂ ਲੈ ਸਕੇ, ਪਛਾਣ ਪੁਸ਼ਟੀ ਕਰੇ, ਪੂਰਾ ਕਰੇ ਅਤੇ ਟ੍ਰੈਕ ਕਰੇ—ਆਡੀਟ ਲੌਗ, ਰੇਡੈਕਸਨ, ਐਕਸਪੋਰਟ ਅਤੇ ਕੰਪਲਾਇੰਸ-ਤਿਆਰ ਰਿਪੋਰਟਿੰਗ ਸਮੇਤ।
ਇੱਕ ਡੇਟਾ ਐਕਸੈਸ ਬੇਨਤੀ—ਜਿਸਨੂੰ ਅਕਸਰ DSAR (Data Subject Access Request) ਜਾਂ SAR ਕਿਹਾ ਜਾਂਦਾ ਹੈ—ਉਸ ਵੇਲੇ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਕੋਈ ਵਿਅਕਤੀ ਤੁਹਾਡੇ ਸੰਗਠਨ ਤੋਂ ਪੁੱਛਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਉਸ ਬਾਰੇ ਕਿਹੜਾ ਨਿੱਜੀ ਡੇਟਾ ਰੱਖਦੇ ਹੋ, ਤੁਸੀਂ ਇਸਨੂੰ ਕਿਸ ਤਰ੍ਹਾਂ ਵਰਤਦੇ ਹੋ, ਅਤੇ ਉਸਨੂੰ ਇਕ ਕਾਪੀ ਦੇਣ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਕਾਰੋਬਾਰ ਗਾਹਕ, ਯੂਜ਼ਰ, ਕਰਮਚਾਰੀ, ਜਾਂ ਸੰਭਾਵੀ ਗ੍ਰਾਹਕ ਦਾ ਡੇਟਾ ਇਕੱਠਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਮੰਨੋ ਕਿ ਇਹ ਬੇਨਤੀਆਂ ਹੋਣਗੀਆਂ।
ਇਨ੍ਹਾਂ ਨੂੰ ਚੰਗੇ ਤਰੀਕੇ ਨਾਲ ਹੈਂਡਲ ਕਰਨਾ ਸਿਰਫ ਜੁਰਮਾਨਿਆਂ ਤੋਂ ਬਚਣ ਲਈ ਨਹੀਂ ਹੈ। ਇਹ ਭਰੋਸੇ ਬਾਰੇ ਹੈ: ਇੱਕ ਸਪਸ਼ਟ, ਇੱਕਸਾਰ ਜਵਾਬ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਆਪਣੇ ਡੇਟਾ ਨੂੰ ਸਮਝਦੇ ਹੋ ਅਤੇ ਲੋਕਾਂ ਦੇ ਅਧਿਕਾਰਾਂ ਦੀ ਕਦਰ ਕਰਦੇ ਹੋ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਪਹਿਲਾਂ GDPR ਅਤੇ CCPA/CPRA ਦੇ ਆਸ-ਪਾਸ ਡਿਜ਼ਾਇਨ ਕਰਦੀਆਂ ਹਨ, ਪਰ ਐਪ ਨੂੰ ਵੱਖ-ਵੱਖ ਅਧਿਕਾਰ ਖੇਤਰਾਂ ਅਤੇ ਅੰਦਰੂਨੀ ਨੀਤੀਆਂ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਲਚਕੀਲਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਆਮ ਬੇਨਤੀ ਦੀਆਂ ਕਿਸਮਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
“Access” ਦੇ ਅੰਦਰ ਵੀ ਦਾਇਰਾ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦਾ ਹੈ: ਇੱਕ ਗਾਹਕ “ਤੁਹਾਡੇ ਕੋਲ ਜੋ ਕੁਝ ਵੀ ਹੈ” ਮੰਗ ਸਕਦਾ ਹੈ, ਜਾਂ ਕਿਸੇ ਖਾਸ ਅਕਾਊਂਟ, ਸਮੇਂ-ਸੀਮਾ, ਜਾਂ ਉਤਪਾਦ ਨਾਲ ਜੁੜਿਆ ਡੇਟਾ ਮੰਗ ਸਕਦਾ ਹੈ।
ਇੱਕ DSAR ਐਪ ਇਨ੍ਹਾਂ ਸਟੇਕਹੋਲਡਰਾਂ ਦੇ ਚੌਰਾਹੇ 'ਤੇ ਬੈਠਦਾ ਹੈ:
ਇੱਕ ਮਜ਼ਬੂਤ DSAR ਵੈੱਬ ਐਪ ਹਰ ਬੇਨਤੀ ਨੂੰ ਸਮੇਂ ਨਾਲ, ਟ੍ਰੇਸਬਲ, ਅਤੇ ਇੱਕਸਾਰ ਬਣਾਉਂਦਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਸਪਸ਼ਟ intake, ਭਰੋਸੇਯੋਗ ਪਛਾਣ ਪ੍ਰਮਾਣਿਕਤਾ, ਸਿਸਟਮ-ਵਿਆਪਕ ਡੇਟਾ ਇਕੱਠਾ ਕਰਨ ਦੀ ਯੋਜਨਾ, ਦਰਖ਼ਤ-ਸ਼ਿਲ੍ਹਾ ਫੈਸਲੇ (ਜ਼ਰੂਰਤ ਪੈਣ 'ਤੇ ਨਾਂ-ਮੰਜ਼ੂਰੀਆਂ), ਅਤੇ ਇਹ ਰਿਕਾਰਡ ਕਿ ਕਿਸਨੇ ਕਿੱਥੇ ਅਤੇ ਕਦੋਂ ਕੀ ਕੀਤਾ।
ਮਕਸਦ ਇੱਕ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਪ੍ਰਕਿਰਿਆ ਬਣਾਉਣਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਅੰਦਰੂਨੀ ਤੌਰ ਤੇ ਅਤੇ ਨਿਯੰਤਰਕਾਂ ਨੂੰ ਵੀ ਸਹੀ ਢੰਗ ਨਾਲ ਦਰਸਾ ਸਕੋ—ਬਿਨਾਂ ਹਰ ਬੇਨਤੀ ਨੂੰ ਇੱਕ ਐਮਰਜੈਂਸੀ ਵਿੱਚ ਬਦਲੇ।
ਸਕ੍ਰੀਨਾਂ ਡਿਜ਼ਾਇਨ ਕਰਨ ਜਾਂ ਟੂਲ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ, ਆਪਣੇ ਸੰਗਠਨ ਲਈ “ਮੁਕੰਮਲ” ਕੀ ਹੈ, ਇਹ ਸਪਸ਼ਟ ਕਰੋ। ਇੱਕ ਡੇਟਾ ਐਕਸੈਸ ਰਿਕਵੇਸਟ ਵੈੱਬ ਐਪ ਤਦ ਕਾਮਯਾਬ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਇਹ ਹਰ ਬੇਨਤੀ ਨੂੰ ਨਿਰੰਤਰ ਤਰੀਕੇ ਨਾਲ intake ਤੋਂ ਡਿਲਿਵਰੀ ਤੱਕ ਲਿਆ ਜਾਂਦਾ, ਕਾਨੂੰਨੀ ਸਮੇਂ-ਸੀਮਾਵਾਂ (GDPR, CCPA ਪ੍ਰਕਿਰਿਆਵਾਂ ਆਦਿ) ਨੂੰ ਪੂਰਾ ਕਰਦਾ, ਅਤੇ ਇੱਕ ਬਚਾਅਯੋਗ ਟ੍ਰੇਲ ਛੱਡਦਾ ਹੈ।
ਆਪਣੇ ਐਪ ਲਈ ਮੁੱਖ DSAR ਵਰਕਫਲੋ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਜੋ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਸਪੋਰਟ ਕਰਨਾ ਵੇਖਣਾ ਚਾਹੀਦਾ ਹੈ:
ਵਿਆਵਹਾਰਿਕ ਰੱਖੋ: ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜੇ ਬੇਨਤੀ ਚੈਨਲ ਕਬੂਲ ਕਰੋਂਗੇ (ਸਿਰਫ ਵੈੱਬ ਫਾਰਮ vs. ਈਮੇਲ/ਮੈਨੂਅਲ ਐਂਟਰੀ), ਕਿਹੜੀਆਂ ਭਾਸ਼ਾਵਾਂ/ਲੋਕੇਲ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਅਤੇ ਕਿਹੜੇ “ਐਜ਼-ਕੇਸ” ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੱਲ ਕਰੋਗੇ (ਸ਼ੇਅਰਡ ਅਕਾਊਂਟ, ਪੁਰਾਣੇ ਕਰਮਚਾਰੀ, ਨਾਬਾਲਿਗ)।
ਲੋੜਾਂ ਨੂੰ KPIs ਵਿੱਚ ਬਦਲੋ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਹਫ਼ਤਿਆਨੇ ਟ੍ਰੈਕ ਕਰ ਸਕੇ:
ਹਰੇਕ ਕਦਮ ਦੀ ਮਾਲਕੀ ਲਿਖੋ: ਪ੍ਰਾਇਵੇਸੀ ਟੀਮ, ਸਪੋਰਟ, ਸੁਰੱਖਿਆ, ਲੀਗਲ। ਉੱਚ-ਸਤਰ 'ਤੇ ਰੋਲ ਅਤੇ ਅਨੁਮਤੀਆਂ ਨਿਰਧਾਰਿਤ ਕਰੋ—ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਇਹਨਾਂ ਨੂੰ access controls ਅਤੇ audit logs ਵਿੱਚ ਤਬਦੀਲ ਕਰੋਗੇ।
ਜੇ ਤੁਸੀਂ ਅੱਗੇ ਚੱਲ ਕੇ ਪ੍ਰਗਤੀ ਦੀ ਰਿਪੋਰਟਿੰਗ ਨੂੰ ਸਟੈਂਡਰਡ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ “ਸਿੰਗਲ ਸੋਰਸ ਆਫ ਟਰੂਥ” ਕੀ ਹੈ (ਐਪ) ਅਤੇ ਕੀ ਕੁਝ ਅੰਦਰੂਨੀ ਰਿਪੋਰਟਿੰਗ ਟੂਲਾਂ ਵਿੱਚ ਐਕਸਪੋਰਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ ਡੇਟਾ ਐਕਸੈਸ ਰਿਕਵੇਸਟ ਵੈੱਬ ਐਪ ਸਿਰਫ ਇਕ ਫਾਰਮ ਅਤੇ ਐਕਸਪੋਰਟ ਬਟਨ ਨਹੀਂ ਹੈ। ਤੁਹਾਡੇ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਕੜੀਆਂ ਮਿਆਦਾਂ, ਆਡੀਟਰਾਂ ਲਈ ਸਬੂਤ ਅਤੇ ਅਕਸਰ ਨੀਤੀ ਬਦਲਾਅ ਨੂੰ ਸਹਾਰਨ ਲਈ ਬਣਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ—ਬਿਨਾਂ ਹਰ ਬੇਨਤੀ ਨੂੰ ਇੱਕ ਕਸਟਮ ਪ੍ਰੋਜੈਕਟ ਬਣਾਏ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਤਿੰਨ "ਚਿਹਰੇ" ਬਣਾਉਂਦੀਆਂ ਹਨ:
ਇਨ੍ਹਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖਣਾ (ਚਾਹੇ ਕੋਡਬੇਸ ਸਾਂਝਾ ਹੋ) permissions, auditing, ਅਤੇ ਭਵਿੱਖ ਦੇ ਬਦਲਾਅ ਬਹੁਤ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
ਇੱਕ ਸਕੇਲ ਕਰਨਯੋਗ DSAR ਵਰਕਫਲੋ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਮੁੱਖ ਸਰਵਿਸਜ਼ 'ਤੇ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ:
ਉਪਯੋਗ ਕਰੋ:
ਜੇ ਤੁਹਾਡੀ ਵਾਲਿ 0ਯੂਮ ਘੱਟ ਹੈ ਅਤੇ ਟੀਮ ਛੋਟੀ ਹੈ, ਤਾਂ ਇੱਕ ਸਿੰਗਲ ਡਿਪਲੋਏਬਲ ਐਪ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ—ਘੱਟ ਹਿੱਸੇ, ਤੇਜ਼ ਇਟਰੇਸ਼ਨ। ਜਦੋਂ ਕਨੈਕਟਰਾਂ ਦੀ ਗਿਣਤੀ, ਟਰੈਫਿਕ, ਜਾਂ ਆਡੀਟ ਲੋੜਾਂ ਵਧਣ, ਤਾਂ ਮਾਡਯੂਲਰ ਸਰਵਿਸਜ਼ ਵੱਲ ਵਧੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਅਪਡੇਟ ਦੇ ਦੌਰਾਨ ਐਡਮਿਨ ਵਰਕਫਲੋ ਖਤਰੇ ਵਿੱਚ ਨਾ ਪਾਓ।
ਜੇ ਤੁਸੀਂ ਇਹ ਘਰ ਵਿੱਚ ਤਿਆਰ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਟੂਲਾਂ ਵਾਂਗ Koder.ai ਮੁਢਲੀ ਇੰਪਲੀਮੇਟੇਸ਼ਨ ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ ਜਿਵੇਂ ਕਿ structured conversation ਤੋਂ ਇੱਕ React-ਅਧਾਰਿਤ ਐਡਮਿਨ ਪੋਰਟਲ ਅਤੇ Go + PostgreSQL ਬੈਕਐਂਡ ਜਨਰੇਟ ਕਰਕੇ।
ਦੋ ਪਲੇਟਫਾਰਮ ਖਾਸ ਫੀਚਰ ਕੰਪਲਾਇੰਸ-ਭਾਰੇ ਵਰਕਫਲੋਜ਼ ਲਈ ਮੌਜੂਦ ਹਨ:
ਤੁਹਾਨੂੰ ਫਿਰ ਵੀ privacy/legal ਦੀ ਮਨਜ਼ੂਰੀ ਅਤੇ security review ਦੀ ਲੋੜ ਹੋਏਗੀ, ਪਰ “ਪਹਿਲਾ ਵਰਤਣਯੋਗ end-to-end ਫਲੋ” ਤੇਜ਼ੀ ਨਾਲ ਤਿਆਰ ਕਰਨ ਨਾਲ ਟੀਮਾਂ ਨੂੰ ਇਹਨਾਂ ਲੋੜਾਂ ਨੂੰ ਜਲਦੀ ਵੈਧ ਕਰਕੇ ਮੁੱਲਾਂਕਣ ਕਰਨ ਵਿੱਚ ਮਦਦ ਮਿਲਦੀ ਹੈ।
ਇੰਟੇਕ ਅਨੁਭਵ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਅਕਸਰ DSAR ਅਤੇ ਪ੍ਰਾਇਵੇਸੀ ਕੇਸ ਸਫਲ ਜਾਂ ਨਾਕਾਮ ਹੁੰਦੇ ਹਨ। ਜੇ ਲੋਕ ਬੇਨਤੀ ਆਸਾਨੀ ਨਾਲ ਨਹੀਂ ਬੇਨਤੀ ਕਰ ਸਕਦੇ—ਜਾਂ ਤੁਹਾਡੀ ਟੀਮ ਇਸਨੂੰ ਜਲਦੀ ਤਰੀਕੇ ਨਾਲ ਤ੍ਰਾਇਅਜ ਨਹੀਂ ਕਰ ਸਕਦੀ—ਤਾਂ ਤੁਸੀਂ ਮਿਆਦਾਂ ਗੁਆਂਢਿਆ, ਬੇਜਰੂਰ ਡੇਟਾ ਇਕੱਠਾ ਕਰਾਂਗੇ, ਜਾਂ ਜੋ ਵਾਅਦਾ ਕੀਤਾ ਗਿਆ ਹੈ ਉਹ ਭੁਲਾਕੇ ਦੇ ਦੋਗਾ ਹੋ ਜਾਵੇਗਾ।
ਇੱਕ ਵਿਅਵਹਾਰਿਕ ਵੈੱਬ ਐਪ ਕਈ ਐਂਟਰੀ ਪੁਆਇੰਟਾਂ ਨੂੰ ਸਹਾਰਦਾ ਹੈ, ਪਰ ਸਭ ਕੁਝ ਇੱਕ ਇਕਾਈ ਕੇਸ ਰਿਕਾਰਡ ਵਿੱਚ ਨਾਰਮਲਾਈਜ਼ ਕਰਦਾ ਹੈ:
ਕੰਜੀ ਹੈ ਇੱਕਸਾਰਤਾ: ਜਿਸ ਵੀ ਚੈਨਲ ਦਾ ਉਪਯੋਗ ਹੋਵੇ, ਨਤੀਜਾ ਉਹੀ ਕੇਸ ਫੀਲਡ, ਉਹੀ ਟਾਈਮਰ, ਅਤੇ ਉਹੀ ਆਡੀਟ ਟ੍ਰੇਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਤੁਹਾਡਾ ਇੰਟੇਕ ਫਾਰਮ ਛੋਟਾ ਅਤੇ ਮਕਸਦੀ-ਚਲਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
"ਸਿਰਫ਼ ਬਹਾਦੁਰ" ਸਮੱਗਰੀ ਲਈ ਸੰਵੇਦਨਸ਼ੀਲ ਵੇਰਵਾ ਨਾ ਮੰਗੋ। ਜੇ ਤੁਹਾਨੂੰ ਹੋਰ ਜਾਣਕਾਰੀ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਬਾਅਦ ਵਿੱਚ verification ਕਦਮ ਵਜੋਂ ਮੰਗੋ।
ਕੇਸ ਸਥਿਤੀਆਂ ਨੂੰ ਸਪਸ਼ਟ ਅਤੇ ਸਟਾਫ ਅਤੇ ਬੇਨਤੀਕਰਤਾਂ ਦੋਹਾਂ ਲਈ ਵੀ ਦਿੱਖਣਯੋਗ ਬਣਾਓ:
received → verifying → in progress → ready → delivered → closed
ਹਰੇਕ ਟ੍ਰਾਂਜ਼ਿਸ਼ਨ ਲਈ ਸਪਸ਼ਟ ਨਿਯਮ ਹੋਣ: ਕੌਣ ਇਸਨੂੰ ਮੂਵ ਕਰ ਸਕਦਾ ਹੈ, ਕਿਹੜਾ ਸਬੂਤ ਲੋੜੀਂਦਾ ਹੈ (ਉਦਾਹਰਣ ਲਈ, verification ਪੂਰਾ), ਅਤੇ ਕੀ ਲੌਗ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਜਦੋਂ ਕੇਸ ਬਣਦਾ ਹੈ, ਤੁਰੰਤ SLA ਟਾਈਮਰ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਲਾਗੂ ਨਿਯਮ ਦੇ ਅਨੁਸਾਰ ਹੋ। ਡੈਡਲਾਈਨ ਨੇੜੇ ਹੋਣ 'ਤੇ ਰਿਮਾਈਂਡਰ ਭੇਜੋ, ਜਦੋਂ ਬੇਨਤੀਕਰਤਾ ਤੋਂ ਸਪੱਸ਼ਟੀਕਰਨ ਦਾ ਇੰਤਜ਼ਾਰ ਹੋਵੇ ਤਾਂ ਘੜੀ ਨੂੰ ਰੋਕੋ, ਤੇ ਐਸਕਲੇਸ਼ਨ ਨਿਯਮ ਜੋੜੋ (ਉਦਾਹਰਣ ਲਈ, ਜੇ ਕੇਸ "verifying" ਵਿੱਚ 5 ਦਿਨ ਰਹਿ ਜਾਂਦਾ ਹੈ ਤਾਂ ਮੈਨੇਜਰ ਨੂੰ ਸੂਚਿਤ ਕਰੋ)।
ਚੰਗੇ ਤਰੀਕੇ ਨਾਲ, intake ਅਤੇ lifecycle ਡਿਜ਼ਾਇਨ ਕੰਪਲਾਇੰਸ ਨੂੰ ਇੱਕ ਅਿੰਬਾਕਸ ਸਮੱਸਿਆ ਤੋਂ ਇੱਕ ਪੇਸ਼ਗੋਈਯੋਗ ਵਰਕਫਲੋ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਪਛਾਣ ਜाँच ਉੱਥੇ ਹੀ ਹੈ ਜਿੱਥੇ ਪ੍ਰਾਇਵੇਸੀ ਕੰਪਲਾਇੰਸ ਹਕੀਕਤ ਬਣਦੀ ਹੈ: ਤੁਸੀਂ ਨਿੱਜੀ ਡੇਟਾ ਜਾਰੀ ਕਰਨ ਵਾਲੇ ਹੋ, ਇਸਲਈ ਤੁਹਾਨੂੰ ਪੂਰਵ-ਪੱਕੀ ਯਕੀਨੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਬੇਨਤੀਕਰਤਾ ਡੇਟਾ ਵਿਅਕਤੀ ਹੈ (ਜਾਂ ਉਸ ਲਈ ਕਾਨੂੰਨੀ ਤੌਰ 'ਤੇ ਕਾਰਵਾਈ ਕਰਨ ਲਈ ਅਧਿਕਾਰਤ ਹੈ)। ਇਸਨੂੰ ਆਪਣੇ ਵਰਕਫਲੋ ਵਿੱਚ ਪਹਿਲੀ-ਕਲਾਸ ਕਦਮ ਵਜੋਂ ਬਣਾਓ, ਨਾ ਕਿ ਬਾਅਦ ਵਿੱਚ ਇੱਕ ਸੋਚ।
ਕਈ ਵਿਕਲਪ ਦਿਓ ਤਾਂ ਕਿ ਮਿਆਰੀ ਯੂਜ਼ਰਾਂ ਨੂੰ ਰੋਕਿਆ ਨਾ ਜਾਵੇ, ਪਰ ਪ੍ਰਕਿਰਿਆ ਹਮੇਸ਼ਾ ਜਾਇਜ਼ ਰਹੇ:
UI ਨੂੰ ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਅਗਲਾ ਕਦਮ ਕੀ ਹੋਵੇਗਾ ਤੇ ਕਿਉਂ। ਜੇ ਹੋ ਸਕੇ, ਲੌਗ-ਇਨ ਗ੍ਰਾਹਕਾਂ ਲਈ ਪਹਿਲਾਂ ਤੋਂ ਜਾਣਕਾਰੀ ਭਰੀ ਰਹੋ ਅਤੇ ਐਸੀ ਵਾਧੂ ਜਾਣਕਾਰੀ ਨਾ ਮਾਂਗੋ ਜੋ ਲੋੜੀਂਦੀ ਨਹੀਂ।
ਤੁਹਾਡਾ ਐਪ ਉਹ ਕੇਸ ਸੰਭਾਲੇ ਜਿੱਥੇ ਬੇਨਤੀਕਰਤਾ ਡੇਟਾ ਵਿਅਕਤੀ ਨਹੀਂ ਹੈ:
ਇਸਨੂੰ ਖਾਸ ਤੌਰ 'ਤੇ ਆਪਣੇ ਡੇਟਾ ਸਕੀਮਾ (ਉਦਾਹਰਣ ਲਈ, “requester” ਵਿਰੁੱਧ “data subject”) ਵਿੱਚ ਮਾਡਲ ਕਰੋ, ਅਤੇ ਅਧਿਕਾਰ ਕਿਵੇਂ ਸਥਾਪਿਤ ਕੀਤਾ ਗਿਆ ਇਹ ਲੋਗ ਕਰੋ।
ਹਰ ਬੇਨਤੀ ਦਾ ਜ਼ਰੂਰੀ ਜੋਖਮ ਇਕੋ ਨਹੀਂ ਹੁੰਦਾ। ਉਹ ਨਿਯਮ ਸੈਟ ਕਰੋ ਜੋ ਆਪਣੇ ਆਪ verification ਬਾਰ ਨੂੰ ਵਧਾਉਂਦੇ ਹਨ ਜਦੋਂ:
ਜਦੋਂ ਤੁਸੀਂ verification ਉੱਪਰ ਚੜ੍ਹਦੇ ਹੋ, ਇੱਕ ਛੋਟਾ, ਸਧਾਰਨ-ਭਾਸ਼ਾ ਕਾਰਨ ਦਿਖਾਓ ਤਾਂ ਜੋ ਇਹ ਯਾਦ ਨਾ ਲੱਗੇ ਕਿ ਇਹ ਮੰਮੂਲੀ ਤੌਰ 'ਤੇ произвольный ਹੈ।
ਵੈਰੀਫਿਕੇਸ਼ਨ ਆਰਟੀਫੈਕਟ (IDs, ਅਥਾਰਟੀ ਡਾਕ, ਆਡੀਟ ਘਟਨਾ) ਨੂੰ ਇਨਕ੍ਰਿਪਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਪਹੁੰਚ ਨਿਯੰਤਰਿਤ ਹੋਵੇ, ਅਤੇ ਕੇਵਲ ਸੀਮਿਤ ਰੋਲ ਲਈ ਦਿੱਖਣਯੋਗ ਹੋਵੇ। ਕੇਵਲ ਜੋ ਲੋੜ ਹੈ ਉਹ ਰੱਖੋ, ਇੱਕ ਸਪਸ਼ਟ ਰੀਟੇਨਸ਼ਨ ਸੀਮਾ ਰੱਖੋ, ਅਤੇ автомੈਟਿਕ ਤੌਰ 'ਤੇ ਮਿਟਾਓ।
ਵੈਰੀਫਿਕੇਸ਼ਨ ਸਬੂਤ ਨੂੰ ਆਪਣੇ ਆਪ ਇੱਕ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਮੰਨੋ, ਅਤੇ ਆਡੀਟ ਟ੍ਰੇਲ ਵਿੱਚ ਪ੍ਰਵੇਸ਼ ਬਿੰਦੂ ਰੱਖੋ ਤਾਂ ਕਿ ਬਾਅਦ ਵਿੱਚ ਕੰਪਲਾਇੰਸ ਸਬੂਤ ਹੋ ਸਕੇ।
ਇੱਕ ਡੇਟਾ ਐਕਸੈਸ ਰਿਕਵੇਸਟ ਐਪ ਉਸ ਦੀ ਮਨਜ਼ੂਰੀ ਤੱਕ ਹੀ ਤਿੰਦਰਾ ਹੈ ਜਿੱਥੇ ਉਸਨੂੰ ਪਤਾ ਹੋਵੇ ਕਿ ਨਿੱਜੀ ਡੇਟਾ ਅاصل ਵਿੱਚ ਕਿੱਥੇ ਰਿਹਾ। ਇੱਕ ਇਕੱਲਾ ਕਨੈਕਟਰ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਪ੍ਰਯੋਗਕ ਇਨਵੈਂਟਰੀ ਬਣਾਓ ਜੋ ਤੁਸੀਂ ਸਮੇਂ ਨਾਲ ਰੱਖ ਸਕੋ।
ਉਹ ਸਿਸਟਮਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਯੂਜ਼ਰ-ਪਹਚਾਣ ਜੋੜਦੇ ਹਨ:
ਹਰ ਸਿਸਟਮ ਲਈ ਦਰਜ ਕਰੋ: ਮਾਲਕ, ਉਦੇਸ਼, ਸਟੋਰ ਕੀਤੀ ਡੇਟਾ ਕਿਸਮਾਂ, ਉਪਲਬਧ ਪਰਛਾਣਕ (email, user ID, device ID), ਕਿਵੇਂ ਪਹੁੰਚ (API/SQL/export), ਅਤੇ ਕੋਈ ਸੀਮਾਵਾਂ (ਰੇਟ ਲਿਮਿਟ, ਰੀਟੇਨਸ਼ਨ, ਵੈਂਡਰ ਟਰਨਅਰਾਉਂਡ)। ਇਹ ਇਨਵੈਂਟਰੀ ਜਦ ਬੇਨਤੀ ਆਉਂਦੀ ਹੈ ਤਾਂ ਤੁਹਾਡਾ "ਸੋਰਸ ਆਫ਼ ਟਰਥ" ਬਣ ਜਾਂਦੀ ਹੈ।
ਕਨੈਕਟਰਾਂ ਨੂੰ ਸ਼ਾਨਦਾਰ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ—ਉਹਨਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਕਨੈਕਟਰਾਂ ਨੂੰ ਐਪ ਤੋਂ ਅਲੱਗ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਅਪਡੇਟ ਕਰ ਸਕੋ ਬਿਨਾਂ ਵਰਕਫਲੋ ਨੂੰ ਭੰਗ ਕੀਤੇ।
ਵੱਖ-ਵੱਖ ਸਿਸਟਮ ਇੱਕੋ ਵਿਅਕਤੀ ਨੂੰ ਵੱਖ-ਵੱਖ ਢੰਗ ਨਾਲ ਵਰਨਨ ਕਰਦੇ ਹਨ। ਖੋਜੇ ਹੋਏ ਰਿਕਾਰਡਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝੇ ਸਕੀਮਾ ਵਿੱਚ ਨਾਰਮਲਾਈਜ਼ ਕਰੋ ਤਾਂ ਜੋ ਸਮੀਖਿਆ ਕਰਨ ਵਾਲੇ ਲੋਕ ਐਪਲ ਨਾਲ ਸੰਤਰੀ ਨਹੀਂ ਕਰ ਰਹੇ। ਇੱਕ ਸਧਾਰਣ, ਕਾਰਜਕਾਰੀ ਮਾਡਲ ਹੋ ਸਕਦਾ ਹੈ:
person_identifier (ਜਿਸ ਤੇ ਤੁਸੀਂ ਮੈਚ ਕੀਤਾ)data_category (profile, communications, transactions, telemetry)field_name ਅਤੇ field_valuerecord_timestampਪ੍ਰੋਵੇਨੈਂਸ ਉਹ ਹੈ ਜੋ ਨਤੀਜਿਆਂ ਨੂੰ ਬਚਾਊ ਬਣਾਉਂਦੀ ਹੈ। ਹਰ ਵੈਲਯੂ ਦੇ ਨਾਲ ਮੈਟਾਡੇਟਾ ਸਟੋਰ ਕਰੋ:
ਜਦੋਂ ਕਿਸੇ ਨੇ ਪੁੱਛਿਆ "ਇਹ ਕਿੱਥੋਂ ਆਇਆ?", ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਠੋਸ ਜਵਾਬ ਹੋਵੇਗਾ—ਅਤੇ ਜਦ ਲੋੜ ਹੋਵੇ ਇਸਨੂੰ ਸਹੀ ਜਾਂ ਮਿਟਾਉਣ ਲਈ ਰਾਹ ਵੀ।
ਇਹ ਤੁਹਾਡੀ ਐਪ ਦਾ "ਇਸ ਵਿਅਕਤੀ ਬਾਰੇ ਸਭ ਕੁਝ ਲੱਭੋ" ਹਿੱਸਾ ਹੈ—ਅਤੇ ਇਹ ਓਹ ਹਿੱਸਾ ਹੈ ਜਿਸ ਨਾਲ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਪ੍ਰਾਈਵੇਸੀ ਖਤਰੇ ਜੁੜੇ ਹੋ ਸਕਦੇ ਹਨ ਜੇ ਇਹ ਲਾਪ਼ਰਵਾਹੀ ਨਾਲ ਕੀਤਾ ਗਿਆ। ਇੱਕ ਵਧੀਆ ਰੀਟਰੀਵਲ ਅਤੇ ਮੈਚਿੰਗ ਇੰਜਣ ਸੋਚ ਸਮਝ ਕੇ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ: ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖੋਜ ਕਰਨ ਲਈ ਕਾਫੀ ਵਿਸਥਾਰ ਕਰਦਾ ਹੈ, ਪਰ ਇੰਨੀ ਹੀ ਤੰਗੀ ਨਾਲ ਤਾਂ ਜੋ ਗੈਰ-ਸਬੰਧਤ ਡਾਟਾ ਨਾ ਖਿੱਚਿਆ ਜਾਏ।
ਆਪਣੇ ਇੰਜਣ ਨੂੰ ਉਹਨਾਂ ਪਰਛਾਣਕਾਂ ਦੇ ਆਸ-ਪਾਸ ਡਿਜ਼ਾਇਨ ਕਰੋ ਜੋ ਤੁਸੀਂ ਇਨਟੇਕ ਦੌਰਾਨ ਭਰੋਸੇਯੋਗ ਤੌਰ 'ਤੇ ਇਕੱਠੇ ਕਰ ਸਕਦੇ ਹੋ। ਆਮ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ email, ਫੋਨ ਨੰਬਰ, customer ID, order number, ਅਤੇ ਮੈਲਿੰਗ ਐਡਰੈਸ।
ਫਿਰ ਉਹ ਪਰਛਾਣਕ ਜੋ ਅਕਸਰ ਉਤਪਾਦ ਅਤੇ ਐਨਾਲਿਟਿਕਸ ਸਿਸਟਮਾਂ ਵਿੱਚ ਮਿਲਦੇ ਹਨ, ਜੋੜੋ:
ਜਿਨ੍ਹਾਂ ਸਿਸਟਮਾਂ ਕੋਲ ਸਥਿਰ ਕੀ ਸਾਂਝਾ ਨਹੀਂ ਹੁੰਦੀ, ਉੱਥੇ fuzzy matching ਸ਼ਾਮਲ ਕਰੋ (ਜਿਵੇਂ ਸਧਾਰਨ ਕੀਤੇ ਨਾਮ + ਪਤਾ) ਅਤੇ ਨਤੀਜਿਆਂ ਨੂੰ "ਉਮੀਦਵਾਰ" ਸਮਝੋ ਜੋ ਸਮੀਖਿਆ ਦੀ ਮੰਗ ਕਰਨ।
"ਪੂਰਾ ਯੂਜ਼ਰ ਟੇਬਲ ਐਕਸਪੋਰਟ" ਕਰਨ ਦੀ ਲਾਲਚ ਤੋਂ ਬਚੋ। ਕਨੈਕਟਰਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਬਣਾਓ ਕਿ ਉਹ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਪਰਛਾਣਕ ਦੁਆਰਾ ਕੋਇਰੀ ਕਰਨ ਅਤੇ ਕੇਵਲ ਸਬੰਧਤ ਫੀਲਡ ਵਾਪਸ ਕਰਨ—ਖਾਸ ਕਰਕੇ ਲੌਗ ਅਤੇ ਇਵੈਂਟ ਸਟ੍ਰੀਮਾਂ ਲਈ। ਘੱਟ ਖਿੱਚਣ ਨਾਲ ਸਮੀਖਿਆ ਸਮਾਂ ਘੱਟ ਹੁੰਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਹੋਰ ਦੀ ਡੇਟਾ ਜਾਰੀ ਕਰਨ ਦਾ ਖਤਰਾ ਵੀ ਘਟਦਾ ਹੈ।
ਇੱਕ ਕਾਰਗਰ ਪੈਟਰਨ ਦੋ-ਕਦਮ ਵਾਲਾ ਹੈ: (1) ਹਲਕਾ "ਕੀ ਇਹ ਪਰਛਾਣਕ ਮੌਜੂਦ ਹੈ?" ਚੈੱਕ ਚਲਾਓ, ਫਿਰ (2) ਪੁਸ਼ਟੀ ਕੀਤੇ ਗਏ ਮਿਲਾਪਾਂ ਲਈ ਫੁਲ ਰਿਕਾਰਡ ਖਿੱਚੋ।
ਜੇ ਤੁਹਾਡੀ ਐਪ ਕਈ ਬ੍ਰਾਂਡ, ਖੇਤਰ, ਜਾਂ ਕਾਰੋਬਾਰੀ ਇਕਾਈਆਂ ਸੇਵਾ ਕਰਦੀ ਹੈ, ਤਾਂ ਹਰ ਪੁੱਛਗਿੱਛ ਵਿੱਚ ਇੱਕ tenant scope ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ। tenant ਫਿਲਟਰਾਂ ਨੂੰ ਕਨੈਕਟਰ ਲੇਅਰ ਵਿੱਚ ਲਾਗੂ ਕਰੋ (ਕੇਵਲ UI ਵਿੱਚ ਨਹੀਂ), ਅਤੇ ਪਰਖਾਂ ਵਿੱਚ ਉਨ੍ਹਾਂ ਦੀ ਸਹੀਤਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ ਤਾਂ ਕਿ ਕ੍ਰਾਸ-ਟੇਨੈਂਟ ਲਿਕੇਜ ਨਾ ਹੋਵੇ।
ਨਕਲੀਆਂ ਅਤੇ ਅਸਪੱਸ਼ਟਤਾਵਾਂ ਲਈ ਯੋਜਨਾ ਬਣਾਓ:
ਮੈਚ confidence, ਸਬੂਤ (ਕਿਹੜਾ ਪਰਛਾਣਕ ਮਿਲਿਆ), ਅਤੇ ਟਾਈਮਸਟੈਂਪ ਸਟੋਰ ਕਰੋ ਤਾਂ ਕਿ ਸਮੀਖਿਆ ਕਰਨ ਵਾਲੇ ਵਿਅਕਤੀ ਇਹ ਸਮਝਾ ਸਕਣ—ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਬਚਾਅ ਕਰ ਸਕਣ—ਕਿ ਕਿਉਂ ਰਿਕਾਰਡ ਸ਼ਾਮਿਲ ਜਾਂ ਬਾਹਰ ਰੱਖੇ ਗਏ।
ਜਦੋਂ ਤੁਹਾਡਾ ਰੀਟਰੀਵਲ ਇੰਜਣ ਸਬੰਧਿਤ ਰਿਕਾਰਡ ਇਕੱਠੇ ਕਰ ਲੈਂਦਾ ਹੈ, ਫਿਰ ਵੀ ਤੁਸੀਂ ਉਹਨੂੰ ਸਿੱਧਾ ਬੇਨਤੀਕਰਤਾ ਨੂੰ ਨਹੀਂ ਭੇਜਨਾ ਚਾਹੀਦਾ। ਜ਼ਿਆਦਾਤਰ ਸੰਗਠਨਾਂ ਨੂੰ ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਤਾਂ ਜੋ ਤੀਸਰੀ-ਪਾਰਟੀ ਨਿੱਜੀ ਡੇਟਾ, ਗੁਪਤ ਕਾਰੋਬਾਰੀ ਜਾਣਕਾਰੀ, ਜਾਂ ਕਾਨੂੰਨ/ਕੰਟ੍ਰੈਕਟ ਦੁਆਰਾ ਸੀਮਿਤ ਸਮੱਗਰੀ ਦਾ ਐਕਸਪੋਜ਼ਰ ਰੋਕਿਆ ਜਾ ਸਕੇ।
ਇੱਕ ਢਾਂਚਾਬੱਧ "ਕੇਸ ਸਮੀਖਿਆ" ਵਰਕਸਪੇਸ ਬਣਾਓ ਜੋ ਸਮੀਖਿਆ ਕਰਨ ਵਾਲੇ ਲੋਕਾਂ ਨੂੰ ਇਹ ਕਰਨ ਦੇਵੇ:
ਇਥੇ ਹੀ ਤੁਸੀਂ ਫੈਸਲਿਆਂ ਨੂੰ ਮਿਆਰੀਕਰਤ ਕਰਦੇ ਹੋ। ਫੈਸਲਿਆਂ ਦੀਆਂ ਇੱਕ ਛੋਟੀ ਸੈੱਟ ਕਿਸਮਾਂ (include, redact, withhold, needs legal review) ਨਾਲ ਜਵਾਬ ਇੱਕਸਾਰ ਅਤੇ ਆਡੀਟ ਲਈ ਆਸਾਨ ਰਹਿੰਦਾ ਹੈ।
ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਸੰਵੇਦਨਸ਼ੀਲ ਹਿੱਸਿਆਂ ਨੂੰ ਹਟਾਉਣ ਅਤੇ ਜਦ ਜਾਰੀ ਨਾ ਕੀਤਾ ਜਾ ਸਕੇ ਪੂਰੇ ਰਿਕਾਰਡ ਨੂੰ ਬਾਹਰ ਰੱਖਣ ਦੋਹਾਂ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਰੇਡੈਕਸਨ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਜਦੋਂ ਡੇਟਾ ਜਾਰੀ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ, ਤਾਂ ਛੂਟਾਂ ਦਾ ਦਸਤਾਵੇਜ਼ ਬਣਾਓ ਅਤੇ ਕਾਰਨ ਬਚਾਓ (ਉਦਾਹਰਣ: ਕਾਨੂੰਨੀ ਛੁੱਟੀ, ਟਰੇਡ ਸੀਕ੍ਰੇਟ, ਜਾਂ ਹੋਰਾਂਤੇ ਨੁਕਸਾਨ)।
ਕੇਵਲ ਡੇਟਾ ਨੂੰ ਲੁਕਾਉਣਾ ਹੀ ਨਹੀਂ—ਫੈਸਲੇ ਦਾ ਤਰਕ ਇੱਕ ਸੰਰਚਿਤ ਢੰਗ ਨਾਲ ਕੈਪਚਰ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਇਸ ਦਾ ਰੱਖਰਖਾਅ ਕਰ ਸਕੋ।
ਜ਼ਿਆਦਾਤਰ DSAR ਵਰਕਫਲੋਜ਼ ਸਭ ਤੋਂ ਚੰਗੇ ਤਰੀਕੇ ਨਾਲ ਦੋ ਡਿਲਿਵਰੇਬਲ ਜਨਰੇਟ ਕਰਦੀਆਂ ਹਨ:
ਹਰੇਕ ਵਿੱਚ ਸਹਾਇਕ ਮੈਟਾਡੇਟਾ ਸ਼ਾਮਲ ਕਰੋ: ਸਰੋਤ, ਸੰਬੰਧਿਤ ਤਰੀਖਾਂ, ਰੇਡੈਕਸਨ/ਛੱਡਣ ਦੇ ਵਜ੍ਹਾ, ਅਤੇ ਸਪਸ਼ਟ ਅਗਲੇ ਕਦਮ (ਸਵਾਲ ਪੁੱਛਣ, ਅਪੀਲ ਕਰਨ, ਡੇਟਾ ਸਹੀ ਕਰਨ ਦੀ ਕਾਰਵਾਈ)। ਇਸ ਨਾਲ ਜਵਾਬ ਸਿਰਫ ਇੱਕ ਡੇਟਾ ਡੰਪ ਨਹੀਂ, ਬਲਕਿ ਸਮਝ ਆਉਣ ਵਾਲਾ ਨਤੀਜਾ ਬਣ ਜਾਂਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਕੇਸਾਂ ਵਿੱਚ ਇੱਕ ਸਥਿਰ ਅਨੁਭਵ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਜਵਾਬ ਟੈਂਪਲੇਟ ਵਰਤੋ ਅਤੇ ਇਸਨੂੰ ਵਰਜਨ ਕੀਤਾ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਦਿਖਾ ਸਕੋ ਕਿ ਕਿਸ ਟੈਂਪਲੇਟ ਨੂੰ fulfillment ਸਮੇਂ ਵਰਤਿਆ ਗਿਆ। ਇਹਨੂੰ ਆਪਣੇ ਆਡੀਟ ਲੌਗਾਂ ਨਾਲ ਜੋੜੋ ਤਾਂ ਕਿ ਪੈਕੇਜ ਵਿੱਚ ਹਰ ਬਦਲਾਅ ਟਰੇਸਬਲ ਹੋਵੇ।
ਸੁਰੱਖਿਆ ਇੱਕ ਐਸਾ ਫੀਚਰ ਨਹੀਂ ਜੋ ਤੁਸੀਂ "ਬਾਅਦ ਵਿੱਚ ਜੋੜੋ"—ਇਹ ਉਹ ਬੁਨਿਆਦ ਹੈ ਜੋ ਸੰਵੇਦਨਸ਼ੀਲ ਨਿੱਜੀ ਡੇਟਾ ਨੂੰ ਰੋਕਦੀ ਹੈ ਅਤੇ ਇਹ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਹਰ ਬੇਨਤੀ ਨੂੰ ਠੀਕ ਢੰਗ ਨਾਲ ਹੈਂਡਲ ਕੀਤਾ। ਮਕਸਦ ਸਪਸ਼ਟ ਹੈ: ਸਿਰਫ ਠੀਕ ਲੋਕ ਹੀ ਠੀਕ ਡੇਟਾ ਵੇਖ ਸਕਣ, ਹਰ ਕਾਰਵਾਈ ਟਰੇਸਬਲ ਹੋਵੇ, ਅਤੇ ਜਨਰੇਟ ਕੀਤੀਆਂ ਫਾਇਲਾਂ ਦੁਰੁਪਯੋਗ ਨਾ ਹੋ ਸਕਣ।
ਸਾਫ਼ ਰੋਲ-ਅਧਾਰਿਤ access control ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਤਾਂ ਕਿ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਬਿਲਕੁਲ ਸਪਸ਼ਟ ਰਹਿਣ। ਆਮ ਰੋਲ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ:
ਅਨੁਮਤੀਆਂ ਨਰਮ ਹੋਣ ਨਾ ਦੇਓ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ reviewer retrieved data ਵੇਖ ਸਕਦਾ ਹੈ ਪਰ deadlines ਨਹੀਂ ਬਦਲ ਸਕਦਾ, ਜਦਕਿ approver ਜਵਾਬ ਜਾਰੀ ਕਰ ਸਕਦਾ ਹੈ ਪਰ connector credentials ਨਹੀਂ ਬਦਲ ਸਕਦਾ।
ਤੁਹਾਡਾ DSAR ਵਰਕਫਲੋ ਇੱਕ append-only ਆਡੀਟ ਲੌਗ ਜਨਰੇਟ ਕਰੇ ਜੋ ਕਵਰ ਕਰੇ:
ਆਡੀਟ ਐਂਟਰੀਜ਼ ਨੂੰ ਛੇਤੀ ਤਬਦੀਲ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਣਾ ਚਾਹੀਦਾ: ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਿਸ ਲਈ ਲਿਖਣ ਦੀ ਪਹੁੰਚ ਸੀਮਤ ਕਰੋ, ਸੋਧਾਂ ਰੋਕੋ, ਅਤੇ ਲਾਗ ਬੈਚਾਂ ਨੂੰ ਹੈਸ਼/ਸਾਈਨ ਕਰਨ ਜਾਂ write-once ਸਟੋਰੇਜ 'ਤੇ ਵਿਚਾਰ ਕਰੋ।
ਆਡੀਟ ਲਾਗ ਵੀ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਅਧਿਆਤਮਿਕ ਫੈਸਲਿਆਂ ਜਿਵੇਂ ਪਾਰਸ਼ੀਅਲ ਡਿਸਕਲੋਜ਼ਰ ਜਾਂ ਅਸਵੀਕਾਰਤਾ ਦੀ ਰੱਖਿਆ ਕਰਦੇ ਹੋ।
ਟ੍ਰਾਂਜ਼ਿਟ ('TLS') ਅਤੇ ਐਟ-ਰੇਸਟ (ਡੇਟਾਬੇਸ, ਆਬਜੈਕਟ ਸਟੋਰੇਜ, ਬੈਕਅੱਪ) ਵਿੱਚ ਇਨਕ੍ਰਿਪਟ ਕਰੋ। ਸੀਕ੍ਰੇਟ (API ਟੋਕਨ, ਡੇਟਾਬੇਸ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ) ਨੂੰ ਇੱਕ ਸਮਰਪਿਤ secret manager ਵਿੱਚ ਰੱਖੋ—ਕੋਡ, ਕਨਫਿਗ ਫਾਇਲਾਂ, ਜਾਂ ਸਪੋਰਟ ਟਿਕਟਾਂ ਵਿੱਚ ਨਹੀਂ।
ਐਕਸਪੋਰਟਾਂ ਲਈ, ਛੋਟੇ-ਅਵਧੀ ਵਾਲੀਆਂ signed download links ਅਤੇ ਜਿੱਥੇ ਲੋੜ ਹੋਵੇ ਇਨਕ੍ਰਿਪਟ ਕੀਤੀਆਂ ਫਾਇਲਾਂ ਵਰਤੋਂ। ਐਕਸਪੋਰਟ ਬਣਾਉਣ ਦੀ ਪਹੁੰਚ ਸੀਮਤ ਕਰੋ ਅਤੇ ਆਟੋਮੈਟਿਕ ਮਿਆਦ ਲਗਾਓ।
ਪ੍ਰਾਇਵੇਸੀ ਐਪਸ ਸਕ੍ਰੈਪਿੰਗ ਅਤੇ ਸੋਸ਼ਲ ਇੰਜੀਨੀਅਰਿੰਗ ਕੋਸ਼ਿਸ਼ਾਂ ਆਕਰਸ਼ਿਤ ਕਰਦੀਆਂ ਹਨ। ਇਹ ਜੋੜੋ:
ਇਹ ਨਿਯੰਤਰਣ ਜੋਖਮ ਘੱਟ ਕਰਦੇ ਹਨ ਅਤੇ ਸਿਸਟਮ ਨੂੰ ਅਸਲ ਗਾਹਕਾਂ ਅਤੇ ਅੰਦਰੂਨੀ ਟੀਮਾਂ ਲਈ ਵਰਤਣਯੋਗ ਰੱਖਦੇ ਹਨ।
DSAR ਵਰਕਫਲੋ ਉਹ ਦੋ ਚੀਜ਼ਾਂ 'ਤੇ ਜੀਉਂਦਾ ਜਾਂ ਮਰਦਾ ਹੈ ਜੋ ਗ੍ਰਾਹਕ ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ: ਕੀ ਤੁਸੀਂ ਸਮੇਂ 'ਤੇ ਜਵਾਬ ਦਿੰਦੇ ਹੋ, ਅਤੇ ਕੀ ਤੁਹਾਡੀਆਂ ਅਪਡੇਟਾਂ ਸਪਸ਼ਟ ਅਤੇ ਭਰੋਸੇਯੋਗ ਲੱਗਦੀਆਂ ਹਨ। ਸੰਚਾਰ ਨੂੰ ਇੱਕ ਪਹਿਲੀ-ਕਲਾਸ ਫੀਚਰ ਸਮਝੋ—ਨਾ ਕਿ ਕੁਝ ਇਮੇਲ ਜੋ ਅੰਤ ਵਿੱਚ ਜੋੜੇ ਗਏ ਹਨ।
ਛੋਟੀ ਸੈਟ ਦੀ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਟੈਂਪਲੇਟਾਂ ਬਣਾਉ ਜੋ ਤੁਸੀਂ ਦੁਹਰਾ ਸਕਦੇ ਹੋ ਅਤੇ ਲੋਕਲਾਈਜ਼ ਕਰ ਸਕਦੇ ਹੋ। ਉਨ੍ਹਾਂ ਨੂੰ ਛੋਟੇ, ਨਿਰਦਿਸ਼ਟ, ਅਤੇ ਕਾਨੂੰਨੀ ਓਵਰਲੋਡ ਤੋਂ ਮੁਕਤ ਰੱਖੋ।
ਆਮ ਟੈਂਪਲੇਟ ਜੋ ਬਣਾਉਣ:
ਵੈਰੀਏਬਲ ਜੋੜੋ (request ID, ਤਾਰਖ਼ਾਂ, ਪੋਰਟਲ ਲਿੰਕ, ਡਿਲਿਵਰੀ ਮੈਥਡ) ਤਾਂ ਜੋ ਐਪ ਸਵੈਚਾਲਿਤ ਤੌਰ 'ਤੇ ਵੇਰਵਾ ਭਰ ਸਕੇ, ਪਰ wording ਉਹੀ ਹੋ ਜੋ ਤੁਹਾਡੇ ਲੀਗਲ/ਪ੍ਰਾਇਵੇਸੀ ਟੀਮ ਨੇ ਮਨਜ਼ੂਰ ਕੀਤਾ ਹੋਵੇ।
ਡੈਡਲਾਈਨਾਂ ਕਾਨੂੰਨ (ਜਿਵੇਂ GDPR vs CCPA/CPRA), ਬੇਨਤੀ ਦੀ ਕਿਸਮ (access, deletion, correction), ਅਤੇ ਇਹ ਕਿ ਪਛਾਣ ਦੀ ਪੁਸ਼ਟੀ ਹੋਈ ਹੈ ਜਾਂ ਨਹੀਂ, ਨਾਲ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਇਹ ਅਕਲਤਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ:
ਡੈਡਲਾਈਨ ਹਰ ਜਗ੍ਹ੍ਹਾ ਦਿੱਖਾਓ: ਕੇਸ ਲਿਸਟ, ਕੇਸ ਡੀਟੇਲ, ਅਤੇ ਸਟਾਫ ਰਿਮਾਈਂਡਰਾਂ।
ਹਰ ਸੰਗਠਨ ਨੂੰ ਇੱਕ ਹੋਰ ਇਨਬਾਕਸ ਨਹੀਂ ਚਾਹੀਦਾ। webhook ਅਤੇ ਈਮੇਲ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਦਿਓ ਤਾਂ ਕਿ ਅਪਡੇਟ ਮੌਜੂਦਾ ਟੂਲਸ (ਉਦਾਹਰਨ ਲਈ helpdesk ticketing system ਜਾਂ ਅੰਦਰੂਨੀ ਚੈਟ) ਨੂੰ ਜਾਣ।
ਇਵੈਂਟ-ਚਲਿਤ ਹੂਕ ਵਰਗੇ ਪ੍ਰਦਾਨ ਕਰੋ: case.created, verification.requested, deadline.updated, ਅਤੇ response.delivered.
ਇੱਕ ਸਾਦਾ ਪੋਰਟਲ back-and-forth ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ: ਗ੍ਰਾਹਕ ਸਥਿਤੀ ਦੇਖ ਸਕਦੇ ਹਨ ("received," "verifying," "in progress," "ready"), ਦਸਤਾਵੇਜ਼ ਅਪਲੋਡ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਨ।
ਡੇਟਾ ਦੇ ਸਮਰਪਣ ਸਮੇਂ, attachments ਤੋਂ ਬਚੋ। ਸਮੇਂ-ਸীমਿਤ, ਪ੍ਰਮਾਣਿਤ ਡਾਉਨਲੋਡ ਲਿੰਕ ਦਿਓ ਅਤੇ ਇਹ ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਲਿੰਕ ਕਿੰਨੀ ਦੇਰ ਲਈ ਵੇਹਦਾ ਰਹੇਗਾ ਅਤੇ ਜੇ ਇਹ ਸਮਾਂ-ਪਾਰ ਹੋ ਜਾਵੇ ਤਾਂ ਕੀ ਕਰਨਾ ਹੈ।
ਰਿਟੇਨਸ਼ਨ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਓਹੁ ਥਾਂ ਹੈ ਜਿੱਥੇ ਇੱਕ DSAR ਟੂਲ "ਵਰਕਫਲੋ ਐਪ" ਤੋਂ ਬਾਹਰ ਆ ਕੇ ਇੱਕ ਕੰਪਲਾਇੰਸ ਸਿਸਟਮ ਬਣ ਜਾਂਦਾ ਹੈ। ਮਕਸਦ ਸਧਾਰਨ ਹੈ: ਜੋ ਰੱਖਣਾ ਲਾਜ਼ਮੀ ਹੈ ਉਹ ਰੱਖੋ, ਜੋ ਨਹੀਂ ਚਾਹੀਦਾ ਉਹ ਮਿਟਾਓ, ਅਤੇ ਸਬੂਤ ਨਾਲ ਇਸਦੀ ਪੇਸ਼ਕਸ਼ ਕਰੋ।
ਰਿਟੇਨਸ਼ਨ ਨੂੰ ਔਬਜੈਕਟ ਟਾਈਪ ਮੁਤਾਬਕ ਨਿਰਧਾਰਿਤ ਕਰੋ, ਕੇਵਲ "ਕੇਸ ਬੰਦ" ਹੀ ਨਹੀਂ। ਇੱਕ ਆਮ ਨੀਤੀ ਅਲੱਗ ਕਰਦੀ ਹੈ:
ਰੀਟੇਨਸ਼ਨ ਅਵਧੀਆਂ ਨੂੰ ਅਧਿਕਾਰ ਖੇਤਰ ਅਤੇ ਬੇਨਤੀ ਦੀ ਕਿਸਮ ਮੁਤਾਬਕ ਸੰਰਚਿਤ ਕਰੋ। ਉਦਾਹਰਣ ਲਈ, ਤੁਸੀਂ ਆਡੀਟ ਲਾਗ ਨੂੰ identity ਸਬੂਤਾਂ ਨਾਲੋਂ ਲੰਬਾ ਰੱਖ ਸਕਦੇ ਹੋ, ਅਤੇ ਡਿਲਿਵਰੀ ਤੋਂ ਬਾਅਦ ਐਕਸਪੋਰਟ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਹਟਾ ਸਕਦੇ ਹੋ ਪਰ ਜੋ ਕੁਝ ਭੇਜਿਆ ਗਿਆ ਉਸਦੇ ਹੈਸ਼ ਅਤੇ ਮੈਟਾਡੇਟਾ ਰੱਖ ਸਕਦੇ ਹੋ ਤਾਂ ਕਿ ਦੱਸਿਆ ਜਾ ਸਕੇ ਕਿ ਕੀ ਭੇਜਿਆ ਗਿਆ ਸੀ।
ਇੱਕ ਸਪਸ਼ਟ legal hold ਸਥਿਤੀ ਜੋ ਮਿਟਾਉਣ ਵਾਲੇ ਟਾਈਮਰਾਂ ਨੂੰ ਰੋਕ ਸਕੇ ਅਤੇ ਸਟਾਫ ਦੀਆਂ ਅਗਲੀ ਕਾਰਵਾਈਆਂ 'ਤੇ ਪਾਬੰਦੀ ਲਗਾ ਸਕੇ, ਸ਼ਾਮਲ ਕਰੋ। ਇਹ ਸਮਰਥਨ ਕਰੇ:
ਨਾਲ ਹੀ exemptions ਅਤੇ limitations (ਉਦਾਹਰਨ: ਤੀਸਰੇ-ਪਾਰਟੀ ਡੇਟਾ, privileged communications) ਦਾ ਮਾਡਲ ਰੱਖੋ। ਉਹਨਾਂ ਨੂੰ ਸੰਰਚਿਤ ਨਤੀਜੇ ਵਜੋਂ behandelen, ਨਾ ਕਿ ਜਸਟ ਫ੍ਰੀ-ਟੈਕਸਟ ਨੋਟ।
ਨਿਯੰਤਰਕ ਅਤੇ ਅੰਦਰੂਨੀ ਆਡੀਟਰ ਆਮ ਤੌਰ 'ਤੇ ਰੁਝਾਨ ਮੰਗਦੇ ਹਨ, ਕਹਿਂ ਕਿ anecdotes ਨਹੀਂ। ਐਹੋ ਜਿਹੇ ਰਿਪੋਰਟ ਬਣਾਓ:
ਰਿਪੋਰਟਾਂ ਨੂੰ ਆਮ ਫਾਰਮੈਟਾਂ ਵਿੱਚ ਐਕਸਪੋਰਟ ਕਰੋ ਅਤੇ ਰਿਪੋਰਟ ਦੀਆਂ ਪਰਿਭਾਸ਼ਾਵਾਂ ਨੂੰ ਵਰਜਨ ਕੀਤਾ ਰੱਖੋ ਤਾਂ ਕਿ ਨੰਬਰ ਸਮਝੇ ਜਾ ਸਕਣ।
ਤੁਹਾਡਾ ਐਪ ਉਹੇ ਨਿਯਮ ਦਰਸਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਤੁਹਾਡਾ ਸੰਗਠਨ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। admin settings ਅਤੇ ਕੇਸ ਵਿਊਜ਼ ਤੋਂ ਅੰਦਰੂਨੀ ਸਰੋਤਾਂ ਜਿਵੇਂ /privacy ਅਤੇ /security ਨੂੰ ਹਵਾਲਾ ਦਿਓ, ਤਾਂ ਜੋ ਆਪਰੇਟਰ ਹਰ ਰੀਟੇਨਸ਼ਨ ਚੋਣ ਦੇ "ਕਿਉਂ" ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕੇ।
ਜਦ UI ਕੰਮ ਕਰ
ਦਾ ਹੋਵੇ ਤਾਂ DSAR ਐਪ "ਤਿਆਰ" ਨਹੀਂ ਹੁੰਦਾ। ਸਭ ਤੋਂ ਜੋਖਿਮ ਭਰੇ ਨਾਕਾਰਮਸ਼ ਹਨ: ਗਲਤ-ਵਿਅਕਤੀ ਦੀਆਂ ਬੇਨਤੀਆਂ, ਕਨੈਕਟਰ ਸਮੇਂ-ਆਉਣ ਤੋਂ ਪਿੱਛੇ, ਅਤੇ ਐਕਸਪੋਰਟ ਜੋ ਚੁਪਕੇ-ਚੁਪਕੇ ਡੇਟਾ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਟੈਸਟਿੰਗ ਅਤੇ ਓਪਰੇਸ਼ਨ ਨੂੰ ਪਹਿਲੀ-ਕਲਾਸ ਫੀਚਰ ਸਮਝੋ।
ਇੱਕ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਟੈਸਟ ਸੂਟ ਬਣਾਓ ਜੋ ਅਸਲ DSAR ਪਿਟਫਾਲਸ 'ਤੇ ਕੇਂਦਰਿਤ ਹੋਵੇ:
ਹਰੇਕ ਕਨੈਕਟਰ ਲਈ "golden" ਫਿਕਸਚਰ ਸ਼ਾਮਲ ਕਰੋ (ਸੰਪਲ ਰਿਕਾਰਡ + ਉਮੀਦ ਕੀਤੀ ਨਤੀਜਾ), ਤਾਂ ਜੋ ਸਕੀਮਾ-ਬਦਲਾਅ ਪਹਿਲਾਂ ਪਤਾ ਲੱਗਣ।
ਓਪਰੇਸ਼ਨ ਮਾਨੀਟਰਨਿੰਗ ਨੂੰ ਐਪ ਹੈਲਥ ਅਤੇ ਕੰਪਲਾਇੰਸ ਨਤੀਜਿਆਂ ਦੋਹਾਂ ਨੂੰ ਕਵਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:
ਮੈਟਰਿਕਸ ਨੂੰ ਸੰਰਚਿਤ ਲੌਗਾਂ ਨਾਲ ਜੋੜੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਜਵਾਬ ਦੇ ਸਕੋ: "ਕਿਹੜਾ ਸਿਸਟਮ ਫੇਲ ਹੋਇਆ, ਕਿਸ ਕੇਸ ਲਈ, ਅਤੇ ਯੂਜ਼ਰ ਨੇ ਕੀ ਦੇਖਿਆ?"।
ਬਦਲਾਅ ਦੀ ਉਮੀਦ ਰੱਖੋ: ਨਵੇਂ ਟੂਲ ਜੋੜੇ ਜਾਣਗੇ, ਫੀਲਡ ਨਾਂ ਬਦਲਣਗੇ, ਅਤੇ ਵੈਂਡਰ ਡਾਊਨ ਹੋ ਸਕਦੇ ਹਨ। ਇੱਕ connector playbook ਬਣਾਓ (ਮਾਲਕ, ਓਥ, auth ਮੈਥਡ, ਰੇਟ ਲਿਮਿਟ, ਜਾਣੇ-ਪਛਾਣੇ PII ਫੀਲਡ) ਅਤੇ ਸਕੀਮਾ-ਚੇਂਜ ਮਨਜ਼ੂਰੀ ਪ੍ਰਕਿਰਿਆ।
ਇੱਕ ਵਰਤਣਯੋਗ ਫੇਜ਼ਡ ਰੋਲਆਊਟ ਯੋਜਨਾ:
ਨਿਰੰਤਰ ਸੁਧਾਰ ਦੀ ਚੈੱਕਲਿਸਟ: ਮਾਸਿਕ ਫੇਲਿਅਰ ਰਿਪੋਰਟਾਂ ਦੀ ਸਮੀਖਿਆ, matching thresholds ਨੂੰ ਟਿਊਨ ਕਰੋ, ਟੈਂਪਲੇਟ ਅਪਡੇਟ ਕਰੋ, ਸਮੀਖਿਆਕਾਰਾਂ ਨੂੰ ਰੀ-ਟ੍ਰੇਨ ਕਰੋ, ਅਤੇ ਘਟਾਉਣ ਲਈ ਅਣ-ਵਰਤੇ ਗਏ ਕਨੈਕਟਰ ਰੀਟਾਇਰ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੇਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਕ ਐਨਵਾਇਰਨਮੈਂਟ ਸਟ੍ਰੈਟਜੀ ਸੋਚੋ ਜੋ ਘੱਟ-ਖਤਰੇ ਰਿਲੀਜ਼ਾਂ ਨੂੰ ਸਮਰਥਨ ਕਰਦੀ ਹੋ (ਉਦਾਹਰਨ ਲਈ, staged deployments ਅਤੇ ਵਾਪਸ ਲੈਣ ਦੀ ਸਮਰੱਥਾ)। Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਤੇਜ਼ ਇਟਰੇਸ਼ਨ, ਡਿਪਲੋਯਮੈਂਟ/ਹੋਸਟਿੰਗ ਅਤੇ ਸਰੋਤ ਕੋਡ ਐਕਸਪੋਰਟ ਨਾਲ ਸਹਾਇਕ ਹੋ ਸਕਦੇ ਹਨ, ਜੋ ਕਿ ਪਾਈਵੇਸੀ ਵਰਕਫਲੋਜ਼ ਅਕਸਰ ਬਦਲਦੀਆਂ ਹਨ ਅਤੇ ਤੁਹਾਨੂੰ ਇੰਪਲੀਮੇਟੇਸ਼ਨ ਅਤੇ ਆਡੀਟੇਬਿਲਟੀ ਨੂੰ ਇਕਠੇ ਰੱਖਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
DSAR (ਇਸਨੂੰ SAR ਵੀ ਕਹਿੰਦੇ ਹਨ) ਉਹ ਬੇਨਤੀ ਹੈ ਜਿਸ ਵਿੱਚ ਕੋਈ ਵਿਅਕਤੀ ਤੁਸੀਂ ਕੋਲੋਂ ਉਸ ਦੇ ਬਾਰੇ ਕਿਹੜੇ ਨਿੱਜੀ ਡੇਟਾ ਰੱਖਦੇ ਹੋ, ਤੁਸੀਂ ਉਸਨੂੰ ਕਿਵੇਂ ਵਰਤਦੇ ਹੋ, ਅਤੇ ਉਸ ਦੀ ਇੱਕ ਕਾਪੀ ਮੰਗਦਾ ਹੈ।
ਇੱਕ DSAR ਵੈੱਬ ਐਪ ਤੁਹਾਨੂੰ ਬੇਨਤੀਆਂ ਨੂੰ ਲੈਣ, ਵੈਰੀਫਾਈ ਕਰਨ, ਖੋਜ ਕਰਨ, ਸਮੀਖਿਆ ਕਰਨ ਅਤੇ ਜਵਾਬ ਪਹੁੰਚਾਉਣ ਵਿੱਚ ਮੱਦਦ ਕਰਦਾ ਹੈ — ਚੰਗੇ ਤਰੀਕੇ ਨਾਲ ਅਤੇ ਸਮੇਂ 'ਤੇ — ਨਾਲ ਹੀ ਇੱਕ ਆਡੀਟ ਟ੍ਰੇਲ ਜੋ ਤੁਸੀਂ ਬਚਾ ਸਕਦੇ ਹੋ।
ਘੱਟੋ-ਘੱਟ ਹੇਠਾਂਲਾ ਸਮਰਥਨ ਯੋਜਨਾ ਵਿੱਚ ਰੱਖੋ:
ਹੇਠਾਂ “Access” ਦੀ ਬੇਨਤੀ ਮਿਥਿ ਹੋ ਸਕਦੀ ਹੈ—ਕੋਰ ਅਕਾਊਂਟ/ਪ੍ਰੋਡਕਟ/ਟਾਈਮਫ੍ਰੇਮ ਲਈ ਲਕੀਨ।
ਇੱਕ ਵਿਅਵਹਾਰਿਕ ਘੱਟੋ-ਘੱਟ ਵਰਕਫਲੋ ਇਹ ਹੈ:
ਜੇ ਤੁਸੀਂ ਇਹ ਕਦਮ end-to-end ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਕਾਨੂੰਨੀ ਮਿਆਦਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੋਵੇਗਾ।
ਉਹ KPIs ਜੋ ਤਵਾਡੇ ਕੰਪਲਾਇੰਸ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਸਿਹਤ ਦੋਹਾਂ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ, ਵਰਤੋ, ਉਦਾਹਰਣ ਲਈ:
ਅਕਸਰ ਟੀਮਾਂ ਤਿੰਨ ਅਲੱਗ ਅਨੁਭਵ ਬਣਾਉਂਦੀਆਂ ਹਨ:
ਇਹਨਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖਣਾ (ਚਾਹੇ ਕੋਡਬੇਸ ਸਾਂਝਾ ਹੋਵੇ) RBAC, ਆਡੀਟ ਅਤੇ ਅੱਗੇ ਚਲਕੇ ਬਦਲਾਅ ਲਈ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
ਕਈ ਤਰੀਕੇ ਪੇਸ਼ ਕਰੋ ਅਤੇ ਜੋਖਮ ਅਨੁਸਾਰ ਉਨ੍ਹਾਂ ਨੂੰ ਉੱਚਾ ਕਰੋ:
ਜੋ ਕੁਝ ਤੁਸੀਂ ਚੈੱਕ ਕਰਦੇ ਹੋ, ਉਹ ਲੌਗ ਕਰੋ, ਸਬੂਤ ਸੁਰੱਖਿਅਤ ਕਰਕੇ ਰੱਖੋ ਅਤੇ ਨਿਰਧਾਰਿਤ ਸਮਾਂ ਬਾਅਦ ਹਟਾਓ।
ਸिस्टम ਇਨਵੈਂਟਰੀ ਬਣਾਉ—ਉਹ ਸਿਸਟਮ ਜੋ ਨਿੱਜੀ ਪਹਚਾਣ ਵਾਲੀ ਜਾਣਕਾਰੀ ਰੱਖਦੇ ਹਨ: ਪ੍ਰੋਡ DBs, ਡੇਟਾ ਵੇਅਰਹਾਊਸ, CRM, ਬਿਲਿੰਗ, ਸਪੋਰਟ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ, ਲੌਗ ਆਦਿ।
ਹਰ ਸਿਸਟਮ ਲਈ ਦਰਜ ਕਰੋ: ਮਾਲਕ, ਉਦੇਸ਼, ਡੇਟਾ ਸ਼੍ਰੇਣੀਆਂ, ਉਪਲਬਧ ਪਰਛਾਣਕ (email, user ID), ਕਿਵੇਂ ਪਹੁੰਚ (API/SQL/export), ਅਤੇ ਕੋਈ ਸੀਮਾਵਾਂ (ਰੈਟ ਲਿਮਿਟ, ਰੀਟੇਨਸ਼ਨ)। ਇਹ ਇਨਵੈਂਟਰੀ ਰਿਕਵੇਸਟ ਆਉਣ 'ਤੇ ਤੁਹਾਡਾ ਸੋਰਸ ਆਫ਼ ਟਰਥ ਬਣੇਗੀ।
ਕਨੈਕਟਰਾਂ ਨੂੰ ਸ਼ਾਨਦਾਰ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ—ਉਹਨਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਕਨੈਕਟਰਾਂ ਨੂੰ ਐਪ ਦੇ ਬਾਕੀ ਹਿੱਸੇ ਤੋਂ ਅਲੱਗ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਅਪਡੇਟ ਕਰ ਸਕੋ ਬਿਨਾਂ ਵਰਕਫਲੋ ਨੂੰ ਤੋੜੇ।
ਅਮਲਕੁਨ matching ਰਣਨੀਤੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਜ਼ਿਆਦਾ ਡੇਟਾ ਇਕੱਠਾ ਕਰਨ ਤੋਂ ਬਚੋ—ਪਹਿਲਾਂ "exists?" ਚੈੱਕ ਚਲਾਓ, ਫਿਰ ਪੁਸ਼ਟੀ ਹੋਣ ਤੇ ਫੁੱਲ ਰਿਕਾਰਡ ਖਿੱਚੋ।
ਸਮੀਖਿਆ ਅਕਸਰ ਲਾਜ਼ਮੀ ਹੁੰਦੀ:
ਡਿਲਿਵਰੇਬਲ ਦੋ ਤਰਾਂ ਦੇ ਬਣਾਓ: ਇੱਕ ਮਨੁੱਖ-ਪੜ੍ਹਨਯੋਗ ਰਿਪੋਰਟ (HTML/PDF) ਅਤੇ ਇੱਕ ਮਸ਼ੀਨ-ਰਿਢੇਐਬਲ ਐਕਸਪੋਰਟ (JSON/CSV)। ਸੁਰੱਖਿਅਤ, ਸੀਮਿਤ ਸਮੇਂ ਵਾਲੀਆਂ ਡਾਊਨਲੋਡ ਲਿੰਕਾਂ ਦਿਓ।
ਹਫ਼ਤਿਆਨੇ ਟ੍ਰੈਕਿੰਗ ਨਾਲ ਤੁਸੀਂ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸੁਧਾਰ ਸਕਦੇ ਹੋ।