Every assignment needs clear agreement on the systems staff may access, the information they may handle and how to report a security concern.
Our approach is to give staff the access needed for their assigned tasks and clear instructions on handling client information.
Project setup must identify the data involved, approved systems, authorized staff and client responsibilities. Confidentiality, access requests, training and incident reporting need to be addressed before work begins. The required safeguards and supporting records depend on the engagement.
Framework references describe the standards and safeguards our operating model can support. They do not represent an independent certification, legal opinion or blanket compliance claim unless that status is specifically documented in writing.
Client & project requirements
Healthcare project planning covers access limits, confidentiality training, approved information-handling procedures and how staff report concerns. Applicable requirements, safeguards and supporting agreements must be confirmed with the client before access is granted.
When a program involves payment-account data, access and technology must remain inside the client-approved cardholder-data environment. General website and inquiry systems are not used to collect card data.
Collection, access, retention, transfer and deletion requirements must reflect the actual engagement and applicable law. Website requests, employee records and client-controlled data can have different rules and responsible parties.
Each campaign needs a review of contact permissions, suppression requests, calling windows, recording rules and approved scripts. Client approval alone does not establish that every contact method is lawful.
Shan supports non-clinical administrative work. Licensed providers retain clinical eligibility, medical necessity, patient-care decisions, orders and final approvals.
Agree which procedures, training records, access lists and reporting are needed for the engagement. Ask for current evidence covering the actual service and systems; a framework reference is not a certification.
Understand what the website protects, what a client project must establish and how to report a concern. Security claims should be supported by evidence for the systems and work they describe.
Last updated:
The public website and staff dashboard are different access areas. Anyone can read public service information and send a relevant inquiry; reviewing submissions or downloading CVs requires authorized dashboard access. Use the HTTPS address and do not bypass a browser certificate warning.
Forms validate required fields, use abuse controls and restrict uploaded CV sizes and permitted file types. Uploaded CVs are held outside the public website folder, and the download route checks account permissions. File validation reduces some risks but is not the same as antivirus scanning or a guarantee that a file is harmless.
An uploaded CV is also attached to the recruitment email. Other submission details can be synchronized to Google Sheets or exported by authorized staff. Protecting only the dashboard is therefore not enough: the email, spreadsheet and downloaded copies have their own access and handling considerations.
The dashboard uses password hashing, server-side permission checks, login throttling, session renewal at authentication and inactivity expiry. Session cookies have security attributes, and protected form actions use anti-forgery checks. Selected administrative actions are recorded for accountability; this should not be interpreted as a log of every access or every action.
Staff should use their assigned accounts, protect passwords and sign out when finished on a shared device. Access needs review when responsibilities change. Dashboard account changes do not automatically remove access from hosting, email, Google Sheets or previously downloaded exports.
This description is limited to the controls identified in the website system. It does not claim universal multi-factor authentication, continuous monitoring, a formal security certification or encryption of every stored record and email attachment.
A project needs an agreed data-handling plan appropriate to the actual work. The following are setup requirements to confirm with the client, not a claim that every possible control is already enabled for every engagement.
HIPAA applies to covered entities and business associates in defined circumstances; it does not automatically apply to every company that mentions healthcare. Whether Shan Communications acts as a business associate depends on the actual services and information handled. Where required, the relevant business-associate agreement and safeguards must be established before protected health information is accessed.
General inquiry and application forms are not approved channels for patient records. Healthcare assignments need client-approved systems, appropriate access restrictions and clear reporting responsibilities. Licensed providers retain clinical decisions. Our discussion of HIPAA is an operating approach, not a claim of HIPAA certification or a legal determination for a particular engagement.
This website does not provide a payment-card checkout, and its general forms must not be used to collect card numbers, security codes or payment credentials. If an engagement involves payment-account data, the applicable PCI DSS scope, systems, responsibilities and required assessment must be determined for that engagement.
A reference to PCI DSS does not mean Shan Communications or every client environment has been independently validated. Ask for the current evidence covering the relevant service and scope before relying on any compliance representation. Keep payment activity within the approved payment environment.
A sales or outreach program needs a campaign-specific review of the audience, country and state, contact method, source of the data, permissions, suppression requests and any applicable calling, recording or commercial-email rules. A client’s instruction, a purchased list or a general website checkbox is not by itself proof that every contact method is lawful.
Before work begins, the parties need to determine which evidence and approvals are required, who maintains them, how opt-out requests reach the operating team and when an uncertain case must be stopped or escalated. References to outreach controls on this page do not certify a particular campaign or override a recipient’s rights.
Security responsibilities continue when information moves into email, a spreadsheet, a document link or an authorized export. Review the actual recipients and sharing permissions; a private dashboard does not make a publicly shared cloud document private.
At the end of an assignment, access removal and any agreed return or deletion of information need to cover the relevant systems and copies. Dashboard Trash is recoverable and does not automatically erase email, spreadsheet or document copies. Retention exceptions and completion evidence must be handled in line with the applicable agreement and law.
The public website does not establish a dedicated hosting environment, a particular backup schedule, guaranteed data residency or a disaster-recovery service level for client work. Those requirements need to be verified for the specific environment and agreed separately.
Contact support using the address below. Include the affected page or system, when you noticed the issue, a clear description and safe steps to reproduce it. Redact screenshots and logs before sharing them. Never include passwords, session tokens, private keys, patient records, complete payment details or a copy of another person’s CV.
If a client engagement is affected, use its agreed escalation channel as well. The response needs to consider the systems, data, affected parties and any applicable notification obligations. This page does not promise a fixed response time or substitute a general support email for an emergency service.
Finding an issue does not authorize access to other users’ records, destructive testing, continued exploitation or public disclosure of private data. Seek written permission before intrusive testing. This page is not a bug-bounty offer or a blanket authorization for security research.
For a proposed engagement, ask for the evidence relevant to its actual risks and contractual requirements. Discuss the scope and date of any assessment, which systems it covers, the responsible parties and any outstanding limitations. A policy statement or framework logo is not a substitute for that evidence.
No website or organization can promise that a security incident will never occur. This page does not claim SOC 2, ISO 27001, PCI DSS validation or any other certification without supporting documentation. Its purpose is to distinguish the website’s identified controls from project requirements that must be confirmed before work begins.
Tell us which services you need, the workload you want to outsource and your preferred timeline. We’ll discuss the scope and next steps with you.