Initial-release version. Published 22 October 2026; applies when expressly accepted. Earlier version 1.0 and recorded acceptances remain unchanged.
1. Who is responsible
Francis Mabala Lemoya operates SHIDA personally from Sweden under the NIHILOBA brand and is the controller for account administration, platform security, public discovery and the operator’s own service operations. NIHILOBA is not an incorporated company, and the operator is not yet registered as a Swedish sole trader.
Contact for privacy requests and service questions: contact@nihiloba.com; Hallonbergsvägen 2A, 17453 Sundbyberg, Sweden. The operator is the privacy contact. No separately appointed DPO or DRC representative is identified by this notice.
2. Scope and other controllers
This notice covers SHIDA's public website, Personal accounts, the connected WhatsApp service and the operator's own processing associated with Business access. Public browsing does not require an account, although technical requests and any enabled audience events still involve data processing.
An employer, seller, service provider, restaurant, hotel or other Organization may independently decide how to use information it receives for a transaction, application or its business obligations. It must provide its own applicable information and rights contact. When SHIDA only hosts private records on an Organization's documented instructions, it may instead act as that Organization's processor. Business processing roles and the Business processing terms apply to the features actually used. They do not authorize new purposes or student-record processing. An account label alone does not decide legal responsibility.
WhatsApp/Meta also processes information for its own service under its own notice. Opening a third-party link takes you to that provider's service.
3. Information and sources
We obtain information you enter on the web, send to SHIDA through WhatsApp or supply to support; information generated by your activities; and relevant information supplied by the counterparty or an authorized Organization member.
- Account and onboarding: your WhatsApp telephone number and sender identifier, name and other profile fields you provide, language, account type choice, onboarding progress, verification state, membership, roles and permissions.
- Legal records: document/version, acceptance time, person accepting, language, channel and applicable Organization context. A Privacy Policy acknowledgement is recorded separately in meaning from optional consent.
- Public content: listings, business contact information you choose to publish, descriptions, location at the displayed level, photos and permitted public reviews. External job discovery may import publicly available job advertisements and source links; this is not an import of private candidate profiles.
- Private activities: applications and supported attachments, order items and amounts, booking/visit/service requests, correspondence, delivery or service address where needed, status changes and records entered by authorized managers. Payment method/status and receipts may be recorded without SHIDA handling the payment itself.
- Communications: messages sent to SHIDA, the relevant activity references, delivery/status information and support or moderation exchanges. SHIDA receives the contents you send to its business account; do not assume those messages are inaccessible to the operator.
- Technical/security information: request time, device/browser information available in requests, IP information in infrastructure logs, session and verification identifiers, security events, permissions/audit history and limited usage events where enabled. Some application counters use hashed identifiers; hashing does not necessarily make information anonymous.
Do not send unnecessary identity documents, health information, criminal records, children's information or other sensitive details in free text, pictures or attachments. A free-text field is not a request for those details.
4. Purposes and legal grounds
Where the GDPR applies, the purpose/basis allocation is as follows. This allocation applies only to the processing described here; a different purpose needs its own assessment and information.
- Creating and administering the Personal service you request, verifying access, completing onboarding, handling your requested activity and delivering essential service messages: performance of the contract with you or steps you request before entering it, limited to what is objectively necessary.
- Preventing fraud, investigating misuse, protecting accounts and maintaining reliable service: the operator's legitimate interests in safe service operation, subject to a documented necessity and rights-balancing assessment. A legal obligation is used only when a specific applicable obligation actually requires the processing.
- Publishing information you intentionally submit for public display and forwarding an application or order to its intended recipient: the requested service, with separate consent where applicable law requires it. We must tell you the recipient and purpose before submission.
- Keeping legal acceptance and necessary dispute evidence: applicable legal obligations where identified, or the legitimate interest in demonstrating compliance and defending claims, with limited access and a justified retention period.
- Optional marketing or non-essential device tracking: prior consent where required. Declining these optional uses must not prevent access to unrelated core services. Service measurement requires its own basis and assessment; calling it analytics does not make it necessary.
The DRC Code's processing and disclosure conditions must be satisfied separately. In particular, its consent/legal-obligation provisions cannot simply be replaced by a GDPR contractual or legitimate-interest basis. Any specific consent required by applicable law must be sought for its stated purpose. You may contact the operator to withdraw consent. Required regulatory formalities are not replaced by this notice. Accepting terms or acknowledging this notice is not a general authorization for all uses or international transfers.
5. Required and optional information
A controlled WhatsApp number and successful verification are required for the current account flow. Without them we cannot complete that flow. The interface should identify other information needed for a particular action, such as a delivery address for delivery. A field needed to perform the particular request must be provided for that request; optional information is not required for unrelated features. Optional profile information and optional marketing choices must not be presented as universally mandatory.
When you ask us to forward information to a counterparty, it will receive the information needed for that activity, subject to the feature's permissions and notices. You should review your submission before sending it.
6. WhatsApp and authentication
The web flow opens a prepared message to SHIDA's configured WhatsApp number. After you send it, SHIDA receives your sender details and message through the WhatsApp Business integration. The service checks the request and sender; where a verification code is returned, it must be entered on the originating web page. Merely opening the link does not sign you in.
The system uses restricted onboarding access before completion and a session after successful completion. Verification and session secrets are not intended for public URLs or analytics. WhatsApp/Meta and network providers still process information necessary to deliver their services. WhatsApp's own processing, storage and deletion are not controlled solely by deleting a SHIDA account. This notice describes the technical flow; it does not represent certification or approval by Meta.
7. Recipients and service providers
Access is limited by purpose and authorization: relevant counterparties, authorized Organization members, personnel handling support/security and contracted infrastructure providers. Public information is available to visitors and may be indexed by search engines. A phone number is not intentionally made public merely by verification, but information you place in public content can become public, and necessary contact information may be shared in an authorized activity.
The systems reviewed use Render for web/application hosting and PostgreSQL infrastructure, Cloudinary integrations for media and supported private documents, and WhatsApp/Meta for messaging and verification delivery. The operator confirms acceptance of data-processing agreements for the existing Render, Cloudinary, Google email, AWS and WhatsApp/Meta accounts. Google handles incoming service email. AWS stores encrypted database backups in Frankfurt. Cloudinary automatic media backups are enabled. These providers may use their own authorized subprocessors and separate processing locations; you may request information about the applicable agreements and safeguards from the operator.
Private documents use access-controlled delivery where the supported private-document feature is enabled; public photos have different access rules. Optional external-job extraction code can use an AI provider, but its production activation and exact data sent have not been confirmed. External-job extraction includes an optional OpenAI integration for public advertisement text. It is not an authorization to transmit private applications. Provider operations and legal safeguards remain subject to the stated purpose and applicable law. This notice does not authorize AI training on applications or private account information.
We may disclose information where a valid legal obligation requires it or where proportionate and lawful to protect rights and investigate abuse. We do not promise absolute secrecy against lawful authority requests. A future operator change requires a lawful, transparent transition; incorporation does not automatically transfer your information to a new company.
8. Countries and transfers
Deployment evidence reviewed places the website in Render's Oregon region in the United States and backend, Business application and database in Frankfurt, Germany. Administration from Sweden, access by intended recipients in the DRC and international provider/subprocessor operations must also be considered. Hosting in Europe does not mean all processing stays in Europe.
International handling must comply with applicable transfer rules. The operator uses the applicable provider processing agreements and must assess any necessary additional safeguards. This notice does not claim a DRC authorization has been issued or that every provider operation remains in Europe. You may ask contact@nihiloba.com for information or a copy of applicable safeguards, with legally justified redactions. No transfer approval or safeguard is claimed to exist by these terms alone.
10. How long information is kept
We must keep identifiable information only for its justified purpose and duration, then erase or genuinely anonymize it unless a specific lawful preservation need applies. Expiry of access or hiding a record is not the same as physical deletion.
The reviewed implementation provides the following technical rules, subject to verification of production configuration and scheduled execution:
- Verification challenges have a short validity capped at five minutes; restricted onboarding sessions default to 30 minutes, authenticated sessions to seven days and cross-service handoffs to 60 seconds. These are access-validity periods, not database-deletion guarantees.
- Inactive onboarding drafts expire after 30 days. Draft expiry prevents continuing the expired draft; it does not by itself erase all stored draft values. You can request erasure through the contact above.
- Raw platform analytics older than 90 days are eligible for cleanup, with an account-deletion path. WhatsApp processed-event replay records have a separate 90-day cleanup rule. This does not establish a 90-day lifetime for WhatsApp message content or every job-analytics record.
- Restaurant delivery-destination handling has a 24-hour post-terminal-state rule and private order history a 12-month rule. Inventory records have a 24-UTC-month policy, but physical inventory deletion is not demonstrated as enabled. Holds and access restrictions must be checked separately.
- Some anti-replay/erasure-barrier digests remain without a defined deletion deadline in the reviewed analytics design. They may still be personal data. These security digests are retained to prevent replay and recreation of erased events; the current implementation has no fixed automatic deletion deadline for them. Separate external-job analytics does not inherit the platform analytics cleanup period.
Account and profile information is retained while the account is used to provide the service. Applications, messages, private files, marketplace records and support exchanges are retained for the requested activity and necessary follow-up; there is no single verified automatic deletion period across these features. On closure or an erasure request, the operator must assess and remove information no longer needed, subject to specific legal recordkeeping or claims requirements. Acceptance and audit evidence is retained only to the extent justified by those requirements. Contact us for the applicable category and any preservation reason; a technical absence of automatic cleanup is not a legal reason to refuse erasure.
Legal acceptance history must not be rewritten. Any continued retention must nevertheless have a documented basis and limited duration. A particular dispute or statutory obligation may require a limited preservation hold; we will explain applicable restrictions when responding to a request. The mere existence of a historic paid record must not be treated as an automatic refusal of all erasure rights.
11. Security and deletion limits
The reviewed design uses access permissions, browser-bound verification, session protections, private-document authorization and controls intended to keep secrets out of logs. No system can promise absolute security. Some deletion, legacy-file and recovery procedures require operator intervention; the availability of code alone does not prove every historical copy has been removed.
Deleting information from the active service may leave restricted backup copies until the verified backup cycle expires; restoration must reapply erasure decisions. The documented Render database recovery window is seven days. Independent encrypted AWS backup tiers have lifecycle periods of 14, 56 and 93 days, with versioning and a 14-day protection lock; provider lifecycle execution can add processing delay. Cloudinary media backups are separate and are not covered by the database periods. Before restoring service, the operator must reconcile later erasure and access-revocation decisions. Ask the operator about a specific retained backup or media copy. Recipients may independently retain information under their own lawful obligations. We will not describe pseudonymized information as anonymous merely because a direct name or number has been removed.
12. Your rights and how to use them
Write to contact@nihiloba.com or use available account controls to request access, correction, erasure, restriction, applicable portability or objection, or to withdraw consent. Where processing relies on legitimate interests you may object on grounds relating to your situation; direct-marketing objections must be honored. Withdrawal does not make earlier lawful consent-based processing unlawful. We may verify your identity proportionately without routinely demanding excessive documents.
Where the GDPR applies, we respond without undue delay and normally within one month. A lawful extension of up to two further months requires notice and reasons within the first month. Rights are subject to the conditions and exceptions in applicable law; if we refuse or restrict a request, we explain why and the available complaint or judicial remedy. You may complain to Sweden's Integritetsskyddsmyndigheten (IMY), or another competent supervisory authority where applicable, without first obtaining our permission.
DRC rights, including applicable instructions concerning data after death, can also be raised through this contact. You may also complain to the competent DRC data-protection authority. The operator can provide the current contact when responding; this notice does not claim that required DRC formalities have been completed. Nothing here removes a more protective applicable right.
13. Children and education
Registration is for adults aged 18 or over, for activities in the Democratic Republic of the Congo. Personal and Business registration are available; no SHIDA platform charges or private student-record service are included. This initial package does not cover actual student records, children's accounts, attendance, grades, school billing tied to pupils or other private education data. A public school profile is distinct from those uses. If such information is submitted inadvertently, contact us so access and the appropriate removal or other lawful response can be assessed. Do not upload it pending a separate education privacy and security release.
14. Automated processing
Technical rules check sessions, permissions, required fields and abuse signals. These are not a promise of human review before every technical rejection. The reviewed initial scope does not include automated hiring decisions or credit scoring by SHIDA. The operator must provide additional information and required safeguards before introducing any qualifying solely automated decision with legal or similarly significant effects. Marketplace counterparties remain responsible for their own decisions and notices. You can ask support to review an access or moderation problem.
15. Updates and languages
Material changes will be explained before they take effect as required by law. A new purpose requiring consent will not be authorized merely by publishing a new policy. Effective dates and immutable version references will be supplied only after approval; historic acceptance records remain intact. French and English are intended to have equivalent meaning, with neither automatically prevailing. Contact us about discrepancies. Lingala and Swahili interfaces must identify any French fallback as French.