Assets like your copy machine may or may not need immediate remediation. Some readers might think that a copy machine might not never need remediation. But if you connect to your networked company machine (or printer) using a browser over HTTPS, it's probably running OpenSSL. And network copy machines and printers are often connected using directory service credentials. Some are even accessible over the Internet. Your mileage may vary.
Step 4: Upgrade what you can
If possible, install a nonvulnerable version of OpenSSL. An alternative is to recompile an existing vulnerable version using the compile time option -DOPENSSL_NO_HeartbeatS.
Step 5: Generate a new key pair
There is always the possibility that your OpenSSL private key was compromised by a previously successful Heartbleed attack. If you plan to continue using a nonvulnerable version of OpenSSL, make sure to generate a new private/public key pair, and begin using that from now on.
Step 6: Mitigate the remaining vulnerable versions
There will probably be instances of vulnerable versions of OpenSSL that you cannot upgrade. It could be mission-critical systems that simply can't be upgraded without going through a huge change control process, or it could be an appliance, device, or software that you literally don't have access to.
In those instances, it makes great sense to keep the bad guys from being able to exploit your vulnerable versions, using any type of filtering (such ad IP whitelisting, domain whitelisting, firewalls, routers, and VLANs.).
Keeping unauthorized parties away from your OpenSSL connections is a good thing to do after you've identified vulnerable versions, but before you've remediated them. Actually, it's a great idea to do all the time with or without a known vulnerability.
For systems not under your control
If you look, you're likely to find many systems you rely upon, either inside your environment or outside of it, that need remediation. Contact their owners or vendors, let them know you've identified a vulnerable version, and ask how they should be remediated.
You're probably not directly aware of every external website that your company relies on. Consider filtering for outbound (or even inbound) SSL/TLS connections to create another list of potential OpenSSL services. The links I've given you above already including information that allows you to test Internet-accessible websites.
Note: The law is not clear on whether "testing" is legal or not. Only test the websites you own or are sure you are legally allowed to test.
Destroy and rebuild
Most serious experts are saying to assume complete compromise on every vulnerable OpenSSL system, and to change every secret associated with the possible compromised system. This means to change all logon credentials stored or access through the system, and contemplate what it might mean if the data on it was compromise, stolen, or adulterated.
If you're going down this route, you probably want to rebuild the system from scratch. When any compromised system you can never be sure that the underlying OS is not been modified in a way to allow a permanent backdoor.
It's worse than bad
Sadly, there are likely to be literally millions of vulnerable installs left unpatched and unmitigated in the real world. Sure, we're going to fix what we find and are allowed to remediate. But so many systems that have a vulnerable version of OpenSSL are probably owned and operated by people that haven't heard about Heartbleed, and won't hear about it. Appliances and systems installed by other people, and even devices they bought and installed by have no clue about whether it is using OpenSSL, much less whether it is vulnerable.
How about that wireless router you have installed at home? How about that new fancy TV? Can you connect to it using HTTPS? If you can, it's probably running an open source Web server and that open source Web server might be running OpenSSL. Perhaps the only saving grace, for millions of people, is that their OpenSSL-enabled device was likely compiled before the last two years, and so they don't contain the Heartbeat vulnerability. Of course if they haven't been updated in two years, they are likely running tons of other vulnerabilities, but at least they aren't all being publicly discussed at the moment.
Do your best due diligence to make sure that you and your company is covered. This isn't just about external, Internet-facing websites. The bad guys routinely get on the internal networks and you can bet that they will be looking for vulnerable versions of OpenSSL with vigor.