Not at all. Once a WorkFlow gets initialized  it can be viewed, halted, delegated, downloaded etc. by anyone with the right permissions. The WorkFlow itself cannot be modified while active i.e. if a WorkFlow is running we can't just delete an event.  What we could do however is open up our WorkFlow in something like Studio, Designer etc. modify it in someway and then redeploy it. What that will do is create two separate versions of the WorkFlow with the newly modified one becoming the default (we can change that). All the old WorkFlows running on the first version will stay on the first verision, but all of the new WorkFlows we initialize will take place on the new default version.

To add to what @Austin said, its all about permissions.  Viewing is easy: grant a user View rights (not View Participate) and then they can view the process at any point.  We had a requirement to allow some users to view a process but not others, so we essentially granted all users View rights then pushed the business logic of viewing the process into the application layer (i.e. our form).

However, to modify data a user needs Admin rights on a process.  This gets sticky because Admin gives a user a host of other things you probably don't want them to be able to do, e.g. delete your entire process (not just one process instance).  There are some things you can do to limit this exposure a bit, but not much.

1. To view status we created a custom view in SQL Server to allow initiator to see their Initiated requests' status.   (Users do not need "View" rights).

     I don't know if there is an existing Sharepoint webpart for tI Initiated] status.

2. You would have to create custom edit feature via K2 API to allow the intitator to update submitted requests.   Application pool can run under the workflow admin's ID and only authorize updates for the initiator's request.   (Users do not need Admin rights to the process)