As an addition to other answers, I'd like to mention some quirks, such as bad sectors, over-provisioning and temporary caches.
TL;DR: use full drive encryption
As you delete files, an SSD has to slowly erase the memory block and only then rerecord it. Instead, SSDs mark the overwritten block as needing erase and copy its data, sans deleted file, to a new block and map it to replace the overwritten one.
This means that if the file was modified or not written in one go, multiple copies of it now exist on SSD flash space until the SSD manages to erase them.
What's more is that it also happens if any file or directory that shares 64kB block with the secret file is modified in any way including just storing last access time.
The SSD should in theory schedule erasure of block that is unmapped (unused/invisible) and not yet erased but in practice unerased data may linger for some extended time.
OS and software, including file-erase software, have no access to this low-level storage space, and in fact are unable to determine if such a scheme is in effect, let alone read or overwrite any "hidden" data. However with forensic tools it may be possible to access it.
A TRIM command is not guaranteed to help as it only marks blocks as needed to be erased (as opposed to being "undeletable" in theory), not forces to erase them. It still is a good idea to enable TRIM if possible as a precaution.
If a drive is near-full when data is deleted or overwritten, the SSD would need to actually erase data before allowing it to be used again, which degrades performance significantly. Instead an SSD has more capacity than it shows to the OS, and uses that while data is still being erased.
For example, drive vendor may decide that for some reason it is best not to erase data in over-provisioned space unless free (erased) space is running low. In this case some data may linger if the drive is not overwritten fast enough. In practice this normally shouldn't happen because of wear leveling though.
What this means is even if you manage to overwrite all 240GB of your drive with 240GB of data, extra 16GB may still contain some of the data, and you have no idea when will it be erased, if at all.
Both HDDs and SSDs may set aside parts of storage space that when read report errors. Nanometer-sized flaws on hard drive platters and flash memory transistors are inevitable and can not be diagnosed in-factory, so drives monitor errors and when they find some they decide to use blocks from a set-aside buffer instead of the "bad" ones. There is a tiny possibility that a part of your file may end up in such a "bad" block and not touched ever since. Forensic experts may recover such data irregardless. It is possible for a very frequently accessed file to end up this way if a power glitch occurs as it is being read or written to.
Drive erase methods
ATA secure erase command should in theory wipe those hidden areas, however that is not explicitly required and some drives would not actually do that.
Device manufacturers' low-level formatting utilities or commands should be more reliable, but often require advanced knowledge and skill and sometimes hardware such as an UART dongle to operate. Such utilities may not be available for every storage device and many have relevant functions disabled for customer (non-authorized professional) use, although unauthorized "leaked" versions are often possible to find.
Regardless, both methods attempt to erase all information on the device, including non-deleted files, programs, OS, and everything else. There are no tools that would actually securely erase a single file.
Encrypting each file individually and then destroying a password should be the way to go. However if the password or code or its precursor is actually also stored on a storage device, instead of you typing it every time the file is accessed, it is also subject to a possibility of ending up stored in a hidden space.
A file password may be only derived from master password which is never written to disk and only stored in memory. This is how some (almost all?) encrypted filesystems work.
Please note that decrypted file may not be temporarily stored on the storage medium like most compression programs (7zip, winrar) do - otherwise it defeats the whole purpose. Only real way to avoid it would be to use an encrypted filesystem, such as truecrypt/veracrypt or NTFS-encryption described above (although I'm not sure if the latter one is foolproof).
Some software, such as MS Word, may also store some parts of your file in temporary files, also defeating the point if the temp directories are not encryped themselves.
Windows explorer may cache previews also possibly defeating it. There may be more leak opportunities depending on software installed such as translation software, smartphone typing prediction, screen readers, etc - even if the software is not instructed to operate on secret files, it may still analyze or cache parts of them.
It should go without saying that any malware or spyware also presents a risk even if offline. So may badly-written corporate "anti-slacking" (worker-spying) software or similar.
Thoughts on mitigation
A hardware-encrypted drive (such as "secure"-labeled USB flash drives) may help mitigate some of the issues, however some of those drives were found to not actually encrypt the data securely enough.
Some OS such as Linux and some "Live-DVDs" may allow to have the majority of OS on a read-only filesystem, eliminating threat of its "contamination" and necessity of OS encryption, however it always causes much headache because you cannot install new software or update software to secure against new threats. Yet it may be a viable solution when military-grade secrecy is required.
In the end it looks like a full drive encryption, including the OS, is the only sure-fire way to go for an ordinary home/office user.