Security and Data Protection Statement

Back to policies

HealthLynk stores and organises information; it does not diagnose, prescribe, provide medical treatment or replace professional medical advice.

HealthLynk Security and Data Protection Statement

Version: 1.0 Effective date: 17 August 2026 Last updated: 17 August 2026

HealthLynk (Pty) Ltd recognises that people entrust HealthLynk with information that may be highly personal and sensitive.

Protecting that information is a fundamental part of how HealthLynk designs, operates and develops its services.

This Security and Data Protection Statement explains the principles and safeguards HealthLynk applies, or commits to applying, to protect personal information and the HealthLynk Service.

It is a public-facing statement and does not disclose confidential technical configurations or security information that could increase risk to our users or systems.

1. About HealthLynk

HealthLynk is operated by:

Legal name: HealthLynk (Pty) Ltd Registration number: 2026/646559/07 Country of registration: Republic of South Africa Director: Yanga Sodoza Website: healthylynk.com Telephone: 074 663 3106 Email: YangaSodoza@outlook.com Business address: 131 Eoan Ave, Eden Heights, Scottsdene, Kraaifontein, Cape Town, Western Cape, South Africa, 7570

HealthLynk provides a digital platform that helps individuals and families securely organise, store, manage, access and share health-related information and documents.

2. Our Security Commitment

HealthLynk aims to protect personal information against risks including:

unauthorised access;
unlawful processing;
accidental disclosure;
alteration;
loss;
destruction;
misuse;
theft;
account compromise; and
inappropriate access by authorised users.

HealthLynk takes a risk-based approach to information security.

Security measures are selected having regard to:

the sensitivity of the information;
foreseeable internal and external threats;
the potential impact on affected people;
the technology being used;
the way information is accessed;
applicable legal obligations; and
generally accepted information-security practices.

Security is an ongoing process rather than a one-time implementation.

3. Health Information Requires Additional Care

HealthLynk may process medical and other health-related information.

This information is treated as particularly sensitive.

Our approach is therefore based on the principle that a person should only be able to access health information when the Service and applicable permissions authorise that access.

HealthLynk does not make private health profiles publicly searchable or publicly available.

HealthLynk does not sell identifiable health information to advertisers or data brokers.

4. Privacy and Security by Design

HealthLynk aims to consider privacy and security throughout the lifecycle of a feature rather than adding security only after development has been completed.

This includes considering:

what information a feature actually needs;
why the information is required;
who should have access;
how long the information needs to remain available;
how access can be limited;
whether sensitive information needs to be displayed;
how information will be transmitted;
how the functionality could be misused;
what could happen if the feature fails;
and how the information can later be corrected, exported or deleted where appropriate.

New functionality involving sensitive personal information should undergo appropriate privacy and security consideration before release.

5. Data Minimisation

HealthLynk aims to collect and process only information reasonably necessary for the functionality being provided or another lawful purpose.

We do not require users to provide unnecessary medical information merely for ordinary activities such as:

contacting support;
cancelling a subscription;
requesting a refund;
reporting a technical issue; or
making a general enquiry.

Where a feature can reasonably operate without additional personal information, HealthLynk aims to avoid collecting that information.

6. Access Control

Access to HealthLynk information is controlled according to the user's account, profile relationships, permissions and functionality available to that user.

Access controls are intended to prevent one user from accessing another person's information merely because that information exists within HealthLynk.

Depending on the relevant feature, controls may include:

authenticated user accounts;
verified email addresses;
profile ownership or management relationships;
invitations;
profile-claim processes;
access permissions;
role-based controls;
administrative-access restrictions; and
other authorisation checks.

HealthLynk follows the principle that access should be limited to what is reasonably required for the relevant purpose.

7. Authentication

HealthLynk uses authentication mechanisms to establish and maintain access to user accounts.

Users are responsible for protecting their own authentication credentials.

HealthLynk's authentication controls may include:

passwords or other credentials;
verified email addresses;
verification codes;
session controls;
automated controls against repeated unauthorised login attempts;
security checks;
and other protective mechanisms appropriate to the Service.

Additional authentication safeguards may be introduced as HealthLynk develops.

8. Privileged and Administrative Access

Administrative access can create greater risk than ordinary user access.

HealthLynk therefore aims to restrict privileged access to persons who reasonably require it to perform authorised operational, security, support or legal responsibilities.

Privileged access should be:

individually attributable where reasonably possible;
limited according to role and responsibility;
protected using appropriate authentication;
reviewed when responsibilities change;
removed when no longer required; and
subject to appropriate logging or accountability controls.

Administrative access must not be used to inspect private health information out of curiosity or for an unrelated purpose.

9. Encryption and Secure Communications

HealthLynk uses or intends to use appropriate encryption to protect information in circumstances where encryption is an appropriate safeguard.

User-facing production communications should be protected using secure encrypted network protocols such as HTTPS/TLS.

Sensitive information stored within production systems should be protected using appropriate storage and infrastructure safeguards, which may include encryption at rest where supported and appropriate.

Passwords must not be stored as readable plain-text credentials.

HealthLynk does not publicly disclose encryption keys, credentials or detailed cryptographic configuration.

Final production encryption configuration will be verified during the pre-launch security review.

10. Secure Application Architecture

HealthLynk aims to separate application responsibilities and restrict unnecessary access between systems.

Infrastructure is configured according to the needs of the Service, with controls intended to limit unintended public exposure of:

databases;
internal services;
administrative interfaces;
credentials;
stored files;
backups; and
other sensitive infrastructure.

Only components that reasonably require public internet access should be exposed publicly.

Detailed network architecture, firewall rules, credentials and security configurations are not published in this Statement.

11. Secure Software Development

HealthLynk incorporates security into its software-development lifecycle.

Depending on the nature of a change, practices may include:

source-control management;
code review;
automated testing;
dependency management;
vulnerability scanning;
application checks;
environment separation;
controlled deployments;
configuration review;
secrets management;
secure coding practices; and
post-deployment verification.

Security-related defects are prioritised according to the nature and potential impact of the risk.

12. Development, Testing and Production Environments

HealthLynk aims to maintain appropriate separation between development activities and live production systems.

Production personal information should not be copied into development or testing environments merely for convenience.

Where representative data is needed for testing, HealthLynk should use:

generated data;
test records;
appropriately de-identified information; or
another method that limits unnecessary exposure of real personal information.

Access to production systems is more restricted than ordinary development access.

13. Secrets and Credentials

Sensitive technical credentials such as:

passwords;
database credentials;
API secrets;
encryption keys;
payment credentials;
cloud credentials; and
other authentication secrets

must not intentionally be embedded in public source code, public documentation or client-visible application content unless they are specifically designed to be public identifiers.

HealthLynk uses or intends to use appropriate secret-management mechanisms for sensitive production credentials.

Credentials should be changed or revoked where compromise is suspected.

14. File and Document Security

HealthLynk allows users to upload health-related documents.

Uploaded information may therefore contain highly sensitive personal information.

HealthLynk applies controls intended to ensure that private uploaded files are not publicly accessible merely because they have been uploaded.

Access to private documents should require appropriate authorisation.

HealthLynk may apply additional controls to uploaded files, including:

file-type restrictions;
file-size restrictions;
storage-access restrictions;
secure download mechanisms;
validation;
malware-related controls where appropriate;
and protective storage configuration.

A user must not intentionally upload malicious files or content designed to compromise the Service.

15. Application Sessions

HealthLynk uses session-management mechanisms to maintain secure authenticated access.

Session controls may include:

secure session identifiers;
expiry;
sign-out functionality;
browser-security attributes;
server-side validation;
invalidation following relevant security events; and
protection against unauthorised reuse.

Users should sign out when using a shared or public device.

16. Protection Against Common Web Risks

HealthLynk aims to apply safeguards appropriate to common web-application threats.

Depending on the applicable functionality, these may include controls addressing risks such as:

unauthorised access;
injection attacks;
cross-site scripting;
cross-site request forgery;
malicious uploads;
brute-force authentication attempts;
insecure direct-object access;
unsafe configuration;
vulnerable dependencies;
session attacks; and
abuse of application functionality.

Security protections are reviewed as threats and the platform evolve.

17. Logging, Monitoring and Auditability

HealthLynk may record operational and security events to support:

detection of suspicious activity;
investigation of incidents;
troubleshooting;
account security;
fraud prevention;
access accountability;
application reliability; and
legal or regulatory obligations.

Logs may include information such as:

event timestamps;
IP addresses;
user or account identifiers;
authentication activity;
security events;
application errors; and
administrative actions.

HealthLynk aims to avoid unnecessarily placing sensitive medical content into ordinary application logs.

Log access is restricted according to operational requirements.

Logs are retained only for periods reasonably appropriate to their purpose and applicable obligations.

18. Backups and Recovery

HealthLynk aims to maintain appropriate backup and recovery arrangements to reduce the risk of permanent data loss.

Depending on the information and infrastructure involved, this may include:

automated backups;
managed database backups;
protected backup storage;
retention controls;
recovery procedures;
and periodic review of recoverability.

Backup copies remain subject to appropriate security controls.

Deletion of information from an active system may not result in immediate deletion from every backup copy.

Backup copies are managed according to their applicable lifecycle and retention requirements.

Final production backup locations, retention periods and recovery procedures will be confirmed during the infrastructure and data-flow audit.

19. Availability and Resilience

HealthLynk aims to design the Service so that reasonable technical failures do not unnecessarily result in permanent loss of information.

Measures may include:

managed infrastructure;
backups;
monitoring;
redundancy where appropriate;
controlled deployments;
recovery procedures; and
infrastructure-health monitoring.

No online service can guarantee uninterrupted availability.

HealthLynk should not be relied upon as the sole source of information required during an immediate medical emergency.

20. Payment Security

HealthLynk intends to use an authorised payment service provider, initially PayFast by Network, to process online subscription payments.

Where payment credentials are entered directly into a payment-provider environment, HealthLynk does not need to receive or store the customer's complete payment-card credentials.

HealthLynk may receive payment information reasonably required to administer subscriptions, such as:

transaction reference;
transaction status;
amount;
subscription status;
recurring-payment reference or token;
and other payment-related metadata.

Access to payment and subscription administration is restricted according to business need.

21. Service Providers and Operators

HealthLynk may use specialist service providers for activities such as:

cloud infrastructure;
data storage;
communication delivery;
payment processing;
security;
monitoring;
backup;
and other operational services.

Where a provider processes personal information on HealthLynk's behalf as an operator, HealthLynk aims to ensure that appropriate confidentiality, processing and security requirements are addressed contractually.

HealthLynk also considers the nature of the information processed when selecting and configuring material service providers.

Our final production operator and data-flow register will identify the material providers relevant to HealthLynk's production environment.

22. Payment Providers Are Not Given Medical Records for Payment Processing

HealthLynk separates payment administration from users' medical records as far as reasonably practical.

A payment provider requires information concerning the transaction and payer, but it should not receive the contents of a user's:

prescriptions;
diagnoses;
test results;
medical documents;
medical history;
or other private health records

merely because it processes the person's HealthLynk subscription payment.

Where information needs to be shared with a payment provider, HealthLynk limits the information according to the payment-processing purpose.

23. Security of Personal Information Processed by Third Parties

Using a service provider does not remove HealthLynk's responsibility to consider how personal information is protected.

HealthLynk therefore aims to:

identify material providers that process personal information;
understand the service being provided;
limit information made available to that provider;
configure provider access appropriately;
assess relevant security capabilities;
maintain appropriate contractual arrangements;
and review providers where risk or the nature of the Service materially changes.

Providers must not use HealthLynk personal information for unrelated purposes merely because they have technical access to systems that process that information.

24. Cross-Border Processing

Some technology providers may operate infrastructure or support services in more than one country.

HealthLynk will assess material international processing and transfers as part of its production data-flow review.

Cross-border processing will be handled in accordance with the HealthLynk Privacy Policy and applicable South African data-protection requirements.

Additional care will be taken where international processing involves:

health information;
children's personal information;
authentication information;
or other particularly sensitive records.

Final production regions, operators and applicable cross-border safeguards remain part of the pre-publication data-flow audit.

25. Children's Information

HealthLynk may store information concerning children where a parent, guardian or other competent person lawfully manages the child's profile.

HealthLynk treats children's information as requiring additional protection.

Security and privacy design involving children's profiles should consider:

who may create the profile;
who may manage it;
how relationships are established;
who may view the information;
how claims or transfers of control operate;
and how the child's privacy interests are protected as circumstances change.

Access to a child's profile does not automatically create authority to disclose that child's information for unrelated purposes.

26. Managed Profiles and Profile Claims

HealthLynk may allow one person to lawfully manage a profile relating to another person.

Where profile invitations or claims are used, security controls may include:

invitation expiry;
email verification;
identity or relationship checks appropriate to the feature;
prevention of unauthorised claims;
duplicate-profile warnings;
access reviews;
and audit information.

The purpose of these controls is to reduce the risk that a person obtains access to another individual's health profile without appropriate authority.

27. Health-Information Exports

HealthLynk may allow users to generate downloadable copies or exports of their information.

Exports create an additional security consideration because once information has been downloaded, it may exist outside HealthLynk's controlled environment.

HealthLynk may therefore use controls such as:

authenticated export requests;
temporary generated files;
expiring download availability;
access checks;
secure delivery mechanisms;
and automatic cleanup.

Users are responsible for protecting files once they have downloaded them to their own devices or independently shared them with another person.

28. Browser and Device Security

HealthLynk can protect information within its own systems, but users' devices are also part of the security chain.

Users should take reasonable steps including:

using a screen lock;
keeping devices updated;
protecting email accounts;
using strong authentication credentials;
avoiding credential sharing;
signing out on shared devices;
avoiding suspicious links;
and taking care when exporting or sharing health information.

HealthLynk may use browser cookies, local storage, caching or PWA technologies as described in the HealthLynk Cookie Policy.

29. Progressive Web Application Security

HealthLynk may be made available as a Progressive Web Application.

PWA functionality can involve browser-side caching and storage.

HealthLynk therefore distinguishes between:

ordinary application assets required to run the Service; and
sensitive personal information.

Sensitive health information should not be persistently cached on a user's device for offline access unless that functionality has been deliberately designed, security-assessed and appropriately communicated to users.

30. Vulnerability and Dependency Management

Modern applications depend on software libraries, frameworks and infrastructure that may occasionally contain security vulnerabilities.

HealthLynk therefore aims to maintain processes for:

identifying known vulnerabilities;
reviewing security advisories;
scanning relevant software dependencies or deployable components;
evaluating affected systems;
prioritising remediation according to risk;
applying updates;
and verifying security-related changes.

A vulnerability does not automatically mean that personal information has been compromised.

Where a vulnerability results in or contributes to a security compromise, HealthLynk will follow the applicable incident-response and notification process.

31. Security Testing

HealthLynk may perform security-related testing appropriate to the maturity and risk of the Service.

This may include:

automated security checks;
dependency scanning;
configuration reviews;
application-security testing;
infrastructure review;
access-control testing;
authentication testing;
and other appropriate assessments.

The depth and frequency of testing may increase as the Service, user base and risk environment grow.

32. Security Incident Response

HealthLynk maintains or will maintain procedures for responding to suspected security incidents.

An incident-response process may include:

detecting or receiving a report of a suspected incident;
assessing the nature of the incident;
taking measures to contain it;
preserving information necessary for investigation;
determining the systems and information affected;
restoring the integrity and security of affected systems;
notifying appropriate internal personnel;
meeting applicable legal or regulatory notification requirements;
informing affected users where required;
addressing underlying weaknesses;
documenting the incident; and
reviewing lessons learned.

HealthLynk's priority during a security incident is to protect affected people and restore the security and integrity of the Service.

33. Personal Information Security Compromises

Where HealthLynk has reasonable grounds to believe that a person's personal information has been accessed or acquired by an unauthorised person, HealthLynk will act in accordance with applicable legal requirements.

This may include notification to:

the Information Regulator; and
affected data subjects.

HealthLynk will not deliberately conceal a reportable personal-information compromise merely to avoid reputational harm.

Where affected users need to take protective action, HealthLynk will provide appropriate information to assist them.

Security-compromise notifications will be managed through the applicable Information Regulator reporting process.

34. Responsible Security Reporting

If you believe you have discovered a security issue affecting HealthLynk, please report it privately rather than publishing sensitive technical details that may put users at risk.

Current security contact: YangaSodoza@outlook.com

This address will be replaced with the official HealthLynk security or support address when available.

When reporting a possible vulnerability:

explain the issue clearly;
describe the affected functionality;
provide enough information for HealthLynk to reproduce the issue where reasonably possible;
do not access information belonging to other users;
do not alter or destroy data;
do not use social engineering;
do not intentionally disrupt the Service;
and do not publicly disclose exploit details while the issue remains unresolved.

HealthLynk will assess good-faith security reports and prioritise genuine risks according to their potential impact.

This section does not establish a paid bug-bounty programme.

35. Business Continuity

HealthLynk aims to maintain reasonable measures for continuing or restoring important services following disruption.

Business-continuity planning may consider events including:

infrastructure failure;
data loss;
cyber incidents;
provider outages;
deployment failures;
credential compromise;
and other material technical disruptions.

Recovery priorities will be determined according to the seriousness of the incident and potential impact on users.

36. Retention and Secure Disposal

Personal information is retained only for as long as there is an appropriate purpose or lawful requirement for retaining it.

When information is no longer authorised to be retained, HealthLynk will delete, destroy or appropriately de-identify it in accordance with the Privacy Policy and applicable requirements.

Technical deletion may be subject to:

backup lifecycles;
security logs;
legal requirements;
transaction records;
and other appropriate retention periods.

Sensitive information should not simply be abandoned in inactive systems after its purpose has ended.

37. Staff, Contractors and Development Partners

People who work on HealthLynk may require different levels of access depending on their responsibilities.

Access to personal information should not be granted merely because someone participates in software development or provides services to HealthLynk.

Where employees, contractors, professional advisers or development partners require access to information or systems, HealthLynk aims to apply appropriate:

confidentiality obligations;
contractual controls;
access restrictions;
authentication requirements;
role separation;
and termination or access-revocation procedures.

38. Security Awareness

Technology alone cannot protect information.

People who have authorised access to HealthLynk systems or business information should understand their responsibilities concerning:

confidentiality;
credentials;
phishing;
suspicious communications;
secure devices;
handling personal information;
incident reporting;
and inappropriate disclosure.

Security practices will develop as HealthLynk grows and additional personnel join the organisation.

39. Physical and Business Security

HealthLynk's security responsibilities are not limited to online systems.

Where physical records, business devices or other offline information contain personal information, HealthLynk will apply safeguards appropriate to the risk.

The company's final registered and operational address arrangements will be reflected in the relevant corporate and compliance documentation.

40. Security Reviews

HealthLynk intends to periodically review its security arrangements.

Reviews may be triggered by:

new functionality;
significant infrastructure changes;
newly identified threats;
security incidents;
new service providers;
legal changes;
new categories of sensitive information;
business growth;
or weaknesses identified during testing.

Where a safeguard is found to be inadequate, HealthLynk aims to update it according to the nature and urgency of the risk.

41. Security and Artificial Intelligence

If HealthLynk introduces artificial-intelligence or automated document-processing functionality in future, additional security and privacy risks will be assessed before deployment.

Considerations may include:

what information is provided to the model or processor;
whether information leaves HealthLynk-controlled infrastructure;
whether a third party may retain the information;
whether information may be used for unrelated model training;
access controls;
data minimisation;
accuracy;
sensitive-health-information exposure;
and contractual protections.

HealthLynk will not assume that a general-purpose AI service is appropriate for confidential health information merely because it is technically capable of processing it.

42. No Sale of Health Information

HealthLynk's security and privacy model is not based on monetising identifiable health records through sale to advertisers or data brokers.

HealthLynk does not sell users' identifiable health information to advertisers or data brokers.

If HealthLynk introduces research, analytics or partnership programmes involving health information in future, they will be assessed independently against applicable privacy, consent, security and ethical requirements.

43. No Absolute Security Guarantee

No organisation, cloud platform or online service can guarantee that a security incident will never occur.

HealthLynk therefore does not claim that its systems are incapable of compromise.

Our commitment is instead to:

take security seriously;
implement safeguards appropriate to the risks;
continually review those safeguards;
respond appropriately to identified weaknesses;
investigate suspected compromises;
comply with applicable notification obligations;
and continue improving the security of the Service.

44. Certifications and Independent Assurance

HealthLynk will not claim to hold a security certification, accreditation or independent assurance report that it has not actually obtained.

For example, HealthLynk will not represent itself as:

ISO/IEC 27001 certified;
SOC 2 certified or attested;
PCI DSS certified as a merchant beyond the actual scope applicable to HealthLynk;
or independently security-audited

unless the relevant certification, assessment or assurance has genuinely been completed and remains applicable.

Security certifications may be considered as HealthLynk grows and the business requirements justify them.

45. Information We Do Not Publish

For the protection of users and the Service, HealthLynk does not publicly disclose information such as:

passwords or credentials;
encryption keys;
complete infrastructure diagrams;
detailed firewall or network rules;
database connection details;
internal administrative URLs;
secret configuration values;
exploitable vulnerability information;
detailed incident-response playbooks;
or other information that could materially assist an attacker.

Appropriate information may nevertheless be disclosed confidentially to regulators, auditors, professional advisers, service providers or other authorised recipients where legitimately required.

46. Relationship With POPIA

HealthLynk processes personal information in accordance with the obligations applicable to it under South African law, including the Protection of Personal Information Act 4 of 2013.

HealthLynk's security programme is intended to support appropriate technical and organisational safeguards for personal information.

Security does not replace HealthLynk's other privacy responsibilities concerning matters such as:

lawful processing;
purpose limitation;
transparency;
data minimisation;
retention;
data-subject rights;
special personal information;
children's information;
and international transfers.

Those matters are addressed in greater detail in the HealthLynk Privacy Policy and POPIA Privacy Notice.

47. Changes to This Statement

HealthLynk may update this Security and Data Protection Statement as:

the Service develops;
security controls change;
infrastructure evolves;
new service providers are introduced;
legal requirements change;
new threats emerge;
or HealthLynk's security programme matures.

The latest version will be published on the HealthLynk website.

Material changes will be reflected in the version number and last-updated date.

48. Contact HealthLynk

For general privacy or security enquiries:

HealthLynk (Pty) Ltd Registration Number: 2026/646559/07 Director: Yanga Sodoza Website: healthylynk.com Email: YangaSodoza@outlook.com Telephone: 074 663 3106 Business address: 131 Eoan Ave, Eden Heights, Scottsdene, Kraaifontein, Cape Town, Western Cape, South Africa, 7570

For suspected security vulnerabilities:

Security contact: YangaSodoza@outlook.com

The contact details will be updated when HealthLynk's official support/security email infrastructure becomes operational.

Pre-Publication Security Verification

Before Version 1.0 is published, HealthLynk will verify that statements in this document accurately reflect the production environment.

The final review will cover at least:

production HTTPS/TLS configuration;
encryption-at-rest configuration;
database security;
uploaded-file storage and access;
production administrative access;
privileged authentication;
secrets management;
production logging;
monitoring;
vulnerability/dependency scanning;
backup configuration;
backup retention;
recovery capability;
operator/service-provider security;
AWS and other infrastructure regions;
email infrastructure;
PayFast integration architecture;
cookie/browser-storage configuration;
profile access and claim controls;
generated-export security;
security-contact arrangements;
incident-response process; and
security-compromise reporting process.

Any statement that cannot be verified will be amended before the document is published.

HealthLynk (Pty) Ltd Your health information. Organised around you.