Log shipping will best meet your criteria. It is supported in standard edition, has the least level of complexity, and can easily be configured to meet your needs around allowable data loss and overall downtime.
It's really important to perform DR tests on a regular basis. This ensures not only that the steps work as expected each time, but also that you are comfortable with performing them during a stressful downtime situation. Consider using a step-by-step solution to help you logically work through the necessary steps to fail over (and back if a DR test).
Also, realize that log shipping is done at the database level and you need to take proactive action to ensure a successful failover. If your failover attempt works great, your databases are running fine on the Secondary, but nobody can actually sign into the application, then unfortunately your efforts have been in vain. Remember to:
- Script out your logins (either automate this via a scheduled job or execute manually as part of each DR test, depending on how frequently your logins change).
- Script out any applicable jobs and copy them to the Secondary server where they should be disabled unless actually needed as part of a true failover.
- Determine whether you have any SSIS packages that may need to be copied across as part of every DR test you perform.
Configure log shipping at a frequency that's appropriate for your RPO and RTO. Probably not necessary to do log shipping this frequently, but then again most of us tend to configure it on the other end of the spectrum and open ourselves up to unnecessary and unacceptable levels of data loss.