I'm going to join the other replies to your question and state that, rule of thumb, index foreign key columns and other columns that you continuously use for range of value searches and sorts (ORDER BY).
Looking at your examples:
CountryID, high selectivity, you'll want to index this one.
CreatedBy and ModifiedBy, probably not. Have you considered doing a bit of refactoring, like altering the insert(s) and update(s) that populate these two columns and modify them to carry not the numeric identifier, but the text string itself? You'd be doing a little denormalizing, sure, but if you're all the time joining to get the text value, and if you don't have a whole lot of people or programs that are inserting and updating (low selectivity), then creating an index on these columns won't help much. If your benchmarking shows that this is a drag on performance, consider this approach.
Status, high selectivity, but this one lends itself to refactoring, also. In many of my columns I've suggested that lookup tables will benefit from a "natural" key rather than a numeric identifier -- and here's a perfect example why. Instead of using a number (1,2,3), derive a 1, 2, or 3-letter code from the status value (OP, CL, WT) and use that as the primary key for the lookup table. Or, better yet, if the status is expressed as a single short word (OPEN, CLOSE, WAIT), use that as the primary key. There's no rule that says you can't have a single-column lookup table. Now, in this foreign key column, instead of a number, you'll be able to see the value, either as a 3-letter code or a short phrase -- both of which are self-explanatory, neither of which require joining to the lookup table in order to decipher.
Indexing for joins is grand, but if you don't have to join, that's the best option!