Security Policy

1. About Pass the MSRA

Pass the MSRA is an online medical education platform established in London, United Kingdom.

In this Policy:

• “Pass the MSRA”, “we”, “us” and “our” refer to the operator of passthemsra.com;
• “platform” means the website, user accounts, dashboards, courses, question banks and associated services;
• “personal information” means information relating to an identified or identifiable individual;
• “you” and “your” refer to a visitor, registered user or customer;
• “security incident” means an event that may affect the confidentiality, integrity or availability of systems, accounts or information.

Security concerns may be reported to:

passthemsra@gmail.com

2. Our security approach

We aim to protect:

• the confidentiality of personal information;
• the integrity of accounts, learning records and website content;
• the availability of the platform;
• payment and transaction information;
• administrative systems;
• backups and operational records.

Our security measures are intended to be proportionate to:

• the nature of the information involved;
• the possible impact of loss or unauthorised access;
• the technology available;
• the cost and practicality of implementation;
• the size and nature of the platform;
• current and reasonably foreseeable threats.

UK data-protection law requires controllers and processors to use appropriate technical and organisational measures to ensure security appropriate to the risk. (Legislation.gov.uk)

3. Website and infrastructure security

Depending on the services and systems in use, security measures may include:

• encrypted HTTPS connections;
• secure hosting controls;
• website application and server protections;
• access restrictions;
• malware and vulnerability monitoring;
• rate limiting or bot protection;
• security logging;
• backups;
• secure configuration;
• software and plugin updates;
• protection against common web attacks;
• monitoring for unusual or unauthorised activity.

The precise controls may differ between the website, hosting provider, payment provider and other third-party services.

We do not claim that every possible attack can be detected or prevented.

4. Encryption

The website should use HTTPS to encrypt information transmitted between the user’s browser and the website.

Encryption in transit reduces the risk of information being intercepted while transmitted over a network.

However, encryption does not remove all risks. Security also depends on:

• device security;
• account credentials;
• server and application configuration;
• administrator access;
• third-party services;
• user behaviour.

Where supported and appropriate, service providers may also encrypt stored information.

5. WordPress, themes and plugins

The platform uses WordPress and associated themes, plugins and integrations.

We aim to reduce security risks by:

• keeping WordPress reasonably up to date;
• maintaining supported themes and plugins;
• removing software that is no longer required where practical;
• reviewing updates for security and compatibility;
• limiting administrative access;
• using reputable sources for software;
• monitoring for known vulnerabilities;
• applying important security updates within a reasonable period.

Updates may occasionally be delayed briefly where immediate installation could create a significant compatibility or service risk. Critical vulnerabilities should be prioritised appropriately.

6. Administrative access

Administrative access should be limited to people and service providers who reasonably require it.

Measures may include:

• separate administrator accounts;
• strong and unique credentials;
• multi-factor authentication where available;
• minimum necessary permissions;
• removal of access when no longer required;
• avoidance of unnecessary shared administrator accounts;
• periodic review of privileged access;
• logging or monitoring of important administrative activity.

The National Cyber Security Centre recommends protecting important online accounts with strong authentication and multi-factor authentication. (National Cyber Security Centre)

7. Password security

Passwords should be stored using secure password-hashing mechanisms provided by the platform rather than in readable plain text.

Users are responsible for:

• choosing a strong and unique password;
• not reusing a password used on another important service;
• keeping login details confidential;
• not sharing accounts;
• protecting access to their email account;
• notifying us promptly of suspected unauthorised access.

Users should never send passwords by email.

We will not normally ask you to disclose your full password.

8. Multi-factor authentication

Where available, multi-factor authentication should be used for:

• hosting accounts;
• domain management;
• payment systems;
• administrator accounts;
• email accounts;
• analytics and advertising accounts;
• backup or cloud-storage services.

Multi-factor authentication may not yet be available for every ordinary student account.

The absence of user-level multi-factor authentication does not remove the user’s responsibility to use a strong and unique password.

9. Account monitoring and misuse prevention

We may monitor activity reasonably necessary to identify:

• repeated failed login attempts;
• suspected credential theft;
• unusual access patterns;
• account sharing;
• automated scraping;
• attempts to bypass restrictions;
• fraudulent transactions;
• excessive or disruptive requests;
• unauthorised administrative activity.

Where a concern is identified, we may:

• temporarily restrict access;
• require a password reset;
• invalidate active sessions;
• request account verification;
• block a suspicious IP address or device;
• investigate the activity;
• suspend an account under the Terms and Conditions.

Security monitoring should be proportionate and handled in accordance with the Privacy Policy.

10. Payment security

Payments may be processed by a specialist payment provider such as Stripe.

Pass the MSRA should not directly store complete payment-card numbers or card-security codes unless a specifically compliant system requires and permits it.

Payment providers may handle:

• card details;
• payment authentication;
• fraud screening;
• tokenisation;
• recurring payment authorisation;
• payment security.

Pass the MSRA may receive limited transaction information such as:

• payment status;
• transaction identifier;
• card brand;
• final digits of a card;
• subscription or customer identifier;
• fraud or authentication results.

Using Stripe or another payment provider can reduce the amount of sensitive card information handled directly, but merchants may still retain responsibilities under PCI DSS depending on the integration used. Stripe advises businesses to determine their integration type and complete the applicable validation requirements. (Stripe Docs)

Accordingly, this Policy does not make an unqualified claim that Pass the MSRA independently stores or manages all payment data in full PCI-DSS-compliant infrastructure.

11. Personal information

Personal information should be processed in accordance with our Privacy Policy.

Security measures may include:

• access restrictions;
• secure authentication;
• minimisation of collected information;
• limited access to support and transaction records;
• secure transmission;
• backups;
• security logging;
• confidentiality obligations;
• deletion or restriction when information is no longer needed.

We aim not to collect more personal information than is reasonably necessary for the relevant purpose.

12. Learning and performance data

Learning records may include:

• question attempts;
• answers;
• scores;
• progress;
• mock-examination performance;
• bookmarks;
• revision history;
• dashboard activity.

This information should be accessible only to:

• the relevant user;
• authorised administrators or support personnel where necessary;
• service providers acting under appropriate instructions;
• others where legally required.

Learning data is not intended to be publicly accessible.

13. Data minimisation

Security is supported by limiting the information collected and retained.

Users should not send:

• identifiable patient information;
• confidential live examination content;
• complete payment-card details;
• account passwords;
• unnecessary identification documents;
• sensitive information unrelated to the request.

Where unnecessary sensitive information is received, we may delete, redact or restrict it where appropriate.

14. Hosting and third-party infrastructure

The platform relies on third-party services that may include:

• hosting providers;
• content-delivery and caching services;
• payment processors;
• email-delivery providers;
• analytics services;
• backup services;
• security tools;
• WordPress plugin providers.

These providers may be responsible for securing parts of the infrastructure they operate.

We aim to select established providers and configure their services appropriately. However, we do not control every aspect of a third party’s security.

Third-party processing of personal information is addressed further in the Privacy Policy.

15. Third-party access

Service providers or contractors should receive access only where reasonably necessary for their role.

Depending on the circumstances, controls may include:

• contractual confidentiality obligations;
• data-processing terms;
• restricted accounts;
• time-limited access;
• minimum necessary permissions;
• removal of access after work is completed;
• supervision or logging of sensitive activity.

We do not promise that every external provider is subject to identical controls, but we aim to apply measures proportionate to the risk and service involved.

16. Backups and recovery

We aim to maintain backups appropriate to the nature of the platform and the hosting arrangements.

Backups may assist with recovery following:

• accidental deletion;
• software failure;
• website corruption;
• unauthorised changes;
• malware;
• hosting failure.

Backup arrangements may include:

• automated hosting backups;
• separate database or file backups;
• retention of more than one restore point;
• restricted access;
• testing or verification of restoration processes where practical.

Backups are not guaranteed to preserve every very recent change or transaction.

The NCSC recommends reliable backups and protecting backup access from compromised administrator accounts. (National Cyber Security Centre)

17. Security updates and vulnerability management

We aim to monitor and respond to security issues affecting:

• WordPress;
• themes;
• plugins;
• hosting infrastructure;
• payment integrations;
• custom code;
• third-party services.

Response may include:

• applying an update;
• disabling a vulnerable feature;
• replacing software;
• introducing a temporary mitigation;
• restricting access;
• investigating affected systems;
• contacting a provider.

The time needed to address a vulnerability may depend on severity, exploitation risk, available patches and compatibility.

18. Secure development and changes

Where custom theme, plugin or Q-bank functionality is developed, reasonable secure-development practices should include:

• input validation;
• output escaping;
• permission checks;
• nonce protection for sensitive WordPress actions;
• prepared database queries;
• least-privilege access;
• protection against cross-site scripting;
• protection against cross-site request forgery;
• protection against SQL injection;
• secure handling of authentication and sessions;
• testing before live deployment;
• separation of development and production work where practicable.

The future Q-bank engine should be built as a separate WordPress plugin and should undergo security review appropriate to its handling of user accounts, attempts and performance data.

19. Logging and monitoring

We may maintain logs to support:

• website operation;
• security investigations;
• fraud prevention;
• error diagnosis;
• account protection;
• detection of automated abuse;
• legal compliance.

Logs may include:

• IP addresses;
• login events;
• administrative actions;
• security alerts;
• error events;
• access requests;
• transaction references;
• device or session information.

Logs should be retained only for as long as reasonably necessary for their purpose, as described in the Privacy Policy.

20. Security incidents

A security incident may include:

• unauthorised account access;
• loss or disclosure of personal information;
• malware;
• compromised administrative credentials;
• unauthorised changes;
• service disruption;
• payment fraud;
• data corruption;
• exploitation of a vulnerability.

When a credible incident is identified, we may:

1. assess and contain the incident;
2. protect affected accounts or systems;
3. preserve relevant evidence;
4. investigate the cause and scope;
5. restore affected services;
6. assess whether personal information was involved;
7. notify service providers or advisers;
8. consider legal and regulatory notification duties;
9. inform affected users where legally required or otherwise appropriate;
10. implement corrective measures.

21. Personal-data breach notification

Not every security incident is a personal-data breach, and not every personal-data breach must be reported to the ICO.

Where a personal-data breach is likely to result in a risk to individuals’ rights and freedoms, the controller must normally notify the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it.

Where the risk is high, affected individuals may also need to be informed without undue delay. (ICO)

We aim to document and assess personal-data breaches in accordance with applicable requirements.

22. Notification to users

Where users need to be informed of an incident, a notification may explain:

• the nature of the incident;
• the information potentially affected;
• actions already taken;
• recommended steps for the user;
• how to reset credentials or secure an account;
• where to obtain further information.

We will not promise notification for every attempted attack, minor technical event or incident that creates no material risk.

23. User responsibilities

Users can help protect their accounts by:

• using a strong and unique password;
• protecting the email account linked to Pass the MSRA;
• not sharing login details;
• avoiding login on untrusted or public devices;
• signing out on shared devices;
• keeping browsers and devices updated;
• avoiding suspicious links;
• confirming that they are using the correct website domain;
• reporting suspected phishing or unauthorised access;
• not attempting to bypass security controls.

Users should contact us promptly if they believe their account has been compromised.

24. Phishing and impersonation

Users should be alert to fraudulent messages pretending to come from Pass the MSRA.

We will not normally ask you by email to provide:

• your complete password;
• your full card number;
• your card-security code;
• online banking credentials;
• remote access to your device.

Suspicious messages should not be answered or followed.

Forward or report relevant details to:

passthemsra@gmail.com

25. Responsible vulnerability reporting

We welcome good-faith reports of genuine security vulnerabilities.

To report a vulnerability, email:

passthemsra@gmail.com

Please include:

• the affected page, feature or system;
• a clear description of the issue;
• steps to reproduce it;
• the potential impact;
• relevant screenshots or technical details;
• your contact information.

Do not include unnecessary personal information.

26. Rules for security researchers

When investigating or reporting a vulnerability, you must not:

• access another user’s account or personal information;
• download or retain personal information;
• modify or delete data;
• disrupt the website;
• perform denial-of-service testing;
• use automated scanning at a harmful rate;
• install malware;
• conduct social-engineering attacks;
• access more information than necessary to demonstrate the issue;
• publish details before we have had a reasonable opportunity to investigate.

Stop testing and notify us immediately if personal information or another user’s account becomes accessible.

This Policy does not grant permission to undertake unlawful access or testing.

27. Handling vulnerability reports

After receiving a credible report, we may:

• acknowledge receipt;
• request further information;
• reproduce the issue;
• assess severity;
• implement a temporary mitigation;
• develop and test a correction;
• notify relevant service providers;
• confirm when the issue has been addressed.

We do not guarantee payment, a bounty or public acknowledgement.

We may decline to engage with reports that are abusive, fraudulent, automated without context or unrelated to a genuine security issue.

28. Availability and resilience

We aim to maintain reasonable availability, but the platform may be interrupted by:

• maintenance;
• upgrades;
• hosting failures;
• cyberattacks;
• third-party outages;
• software bugs;
• emergency security action;
• events outside our reasonable control.

Security may occasionally require us to:

• disable a feature;
• suspend login;
• invalidate sessions;
• force password resets;
• temporarily restrict access;
• place the website in maintenance mode.

Such action may be taken without advance notice where necessary to protect users or systems.

29. No guarantee of absolute security

No online service can be guaranteed to be entirely secure, continuously available or free from vulnerabilities.

Reasonable security measures reduce risk but cannot eliminate:

• unknown vulnerabilities;
• sophisticated attacks;
• user credential compromise;
• third-party failure;
• device malware;
• internet interception;
• human error.

Nothing in this section limits rights or responsibilities that cannot lawfully be excluded.

30. Changes to this Policy

We may update this Policy to reflect:

• changes in technology;
• changes to hosting or service providers;
• new security controls;
• new platform features;
• legal or regulatory developments;
• lessons from security incidents;
• clarification of existing wording.

The current version will display a revised “Last updated” date.

We will not normally publish highly detailed information that would materially weaken security or assist attackers.

31. Contact

Security questions, suspected account compromise and vulnerability reports may be sent to:

Pass the MSRA

London, United Kingdom

Email: passthemsra@gmail.com

Please do not send:

• passwords;
• complete payment-card details;
• identifiable patient information;
• unnecessary copies of identity documents;
• confidential live examination material.